Jonathan Cook - Online wrote:
> Paul,
>
> This is all really useful and really great information.
>
> Back to state, not just user state but any type of application state you
> may wish to store, is there a standard way of storing/managing state in
> Jersey/REST?
There are really two kinds of state in RESTful Web services, application
state that is stored on the client and is sent to the server, and
resource state that is stored on the server and sent to the client when
a client operates on the URI of a resource.
There is no standard way of storing resource state with Jersey (see later).
> I know one of the key principles of REST is that your
> service should be stateless but its a fact of life that sometimes you
> have to store state.
>
This is a common misconception :-) the stateless constraint is about
*communication*, from Roy's thesis [1]:
We next add a constraint to the client-server interaction:
communication must be stateless in nature, as in the
client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3),
such that each request from client to server must contain all of the
information necessary to understand the request, and cannot take
advantage of any stored context on the server. Session state is
therefore kept entirely on the client.
...
Like most architectural choices, the stateless constraint reflects a
design trade-off. The disadvantage is that it may decrease network
performance by increasing the repetitive data (per-interaction
overhead) sent in a series of requests, since that data cannot be left
on the server in a shared context. In addition, placing the
application state on the client-side reduces the server's control over
consistent application behavior, since the application becomes
dependent on the correct implementation of semantics across multiple
client versions.
I recommend reading section 4.5 of RESTful Web services book:
Statelessness means that every HTTP request happens in complete
isolation. When the client makes an HTTP request, it includes all
information necessary for the server to fulfill that request. The
server never relies on information from previous requests. If that
information was important, the client would have sent it again in this
request.
More practically, consider statelessness in terms of addressability.
Addressability says that every interesting piece of information the
server can provide should be exposed as a resource, and given its own
URI. Statelessness says that the possible states of the server are
also resources, and should be given their own URIs. The client should
not have to coax the server into a certain state to make it receptive
to a certain request.
> I just wondered what your views were, store in a database or an in
> memory model or some other cool RESTful approach :)
>
Jersey is agnostic about how and where data is stored for resource state
i.e. it is not like Ruby on Rails. Some people have used databases with
Java APIs like JPA or iBatis. Others just use a file system, or one
could use the Java Content Repository API (something i would like to try
out).
Hudson uses a file system and caches resource state in memory. The
RESTful Web services plugin for NetBeans exposes database tables
directly as resources using JPA. One could write a Jersey service to
call one or more other services to manipulate resource.
My preference is to use tools in conjunction with Jersey to aid the
management of state w.r.t. resources.
Hope this helps,
Paul.
[1]
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3
> Jonathan
>
> -----Original Message-----
> From: Jonathan Cook - Online
> Sent: 08 April 2008 13:06
> To: 'Paul.Sandoz_at_Sun.COM'
> Cc: users_at_jersey.dev.java.net
> Subject: RE: HttpSession
>
> Thanks very much!! This is great.
>
> -----Original Message-----
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: 08 April 2008 12:46
> To: Jonathan Cook - Online
> Cc: users_at_jersey.dev.java.net
> Subject: Re: HttpSession
>
> Jonathan Cook - Online wrote:
>> Paul,
>>
>> If I try to inject the servlet request using:
>> @HttpContext HttpServletRequest r;
>>
>
> I am guessing you are using jersey 0.5 or less... add the jsr250-api.jar
> to your classpath and use:
>
> @Resource HttpServletRequest r;
>
> Otherwise if you switch to 0.6 then HttpContext has been renamed to
> Context and you no longer require the jsr250-api.jar in the classpath
> and you do:
>
> @Context HttpServletRequest r;
>
> The reason we switched was because we were using @Resource incorrectly.
>
>
> Note that the example per session provider i sent out earlier will only
> work for 0.6 or greater.
>
> Paul.
>
>> I get the following error:
>>
>> 2008-04-08 12:18:52.335::WARN: Error for /footballfixtures
>> java.lang.NoClassDefFoundError: javax/annotation/Resource at
>> com.sun.ws.rest.spi.container.servlet.ServletContainer$1.getAnnotation
>> Class(ServletContainer.java:276) at
>> com.sun.ws.rest.spi.resource.Injectable.inject(Injectable.java:52)
>> at
>> com.sun.ws.rest.impl.application.WebApplicationImpl.injectResources(We
>> bApplicationImpl.java:197)
>> at
>> com.sun.ws.rest.impl.application.WebApplicationImpl.injectResources(We
>> bApplicationImpl.java:189)
>> at
>> com.sun.ws.rest.impl.application.WebApplicationContext.injectDependenc
>> ies(WebApplicationContext.java:95)
>> at
>> com.sun.ws.rest.impl.resource.PerRequestProvider.getInstance(PerReques
>> tProvider.java:70)
>> at
>> com.sun.ws.rest.impl.application.WebApplicationContext.getResource(Web
>> ApplicationContext.java:127)
>> at
>> com.sun.ws.rest.impl.uri.rules.ResourceClassRule.accept(ResourceClassR
>> ule.java:49)
>> at
>> com.sun.ws.rest.impl.uri.rules.RightHandPathRule.accept(RightHandPathR
>> ule.java:83)
>> at
>> com.sun.ws.rest.impl.uri.rules.RootResourceClassesRule.accept(RootReso
>> urceClassesRule.java:49)
>> at
>> com.sun.ws.rest.impl.application.WebApplicationImpl.handleRequest(WebA
>> pplicationImpl.java:246)
>> at
>> com.sun.ws.rest.spi.container.servlet.ServletContainer.service(Servlet
>> Container.java:123) at
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
>> at
>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:36
>> 2) at
>> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:18
>> 1) at
>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:72
>> 6) at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:15
>> 2) at org.mortbay.jetty.Server.handle(Server.java:324)
>> at
>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505
>> )
>> at
>> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpCon
>> nection.java:828) at
>> org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>> at
>> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.j
>> ava:228)
>> at
>> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.
>> java:450)
>>
>> maybe I have some missing jar?
>>
>> Jonathan
>>
>> http://www.bbc.co.uk
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically
>> stated.
>> If you have received it in error, please delete it from your system.
>> Do not use, copy or disclose the information in any way nor act in
>> reliance on it and notify the sender immediately.
>> Please note that the BBC monitors e-mails sent or received.
>> Further communication will signify your consent to this.
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109