Did you read what I wrote? We are running in circles.
Am Freitag, den 10.06.2016, 15:49 -0600 schrieb Trenton D. Adams:
> REpresentational State Transfer = Transferring the state with every
> request. Sending a cookie transfers a token to the state, unless the
> cookie contains all of the state, which would be awkward.
>
> On Fri, Jun 10, 2016 at 3:45 PM, Robert Gacki <robert.gacki_at_contenttr
> ace.org> wrote:
> > Again: If you use cookies, you are "REST-compliant". It's just a
> > header.
> >
> > Yes, in your example, sending the data of page 1 also in page 2 is
> > a
> > good and simple solution, and is sufficient if you don't want the
> > client to be able to continue on page 2, after the client lost its
> > state. Its how we built wizards "in the dark ages of the web".
> >
> > If you need the client to resume from page 2, you can also do
> > something
> > like the following requests / responses:
> >
> > -- req/1 -----------------------------------
> > GET /wizard HTTP/1.1
> > Accept: text/html
> >
> > -- res/1
> > HTTP/1.1 200 OK
> > Content-Type: text/html
> >
> > <form action="/wizard" method="post"></form>
> >
> >
> > -- req/2 -----------------------------------
> > POST /wizard/1234/step1 HTTP/1.1
> > Content-Type: application/x-www-form-urlencoded
> > Accept: text/html
> >
> > formdata
> >
> > -- res/1
> > HTTP/1.1 201 Created
> > Content-Type: text/html
> > Location: /wizard/1234/step1
> >
> > <form action="/wizard/1234/step2" method="post"></form>
> > <a rel="self" href="/wizard/1234/step1">Link to this step</a>
> >
> > -- req/3 -----------------------------------
> > POST /wizard/1234/step2
> > HTTP/1.1
> > Content-Type: application/x-www-form-urlencoded
> > Accept:
> > text/html
> >
> > formdata
> >
> > -- res/1
> > HTTP/1.1 200 OK
> > Content-Type: text/html
> >
> > <p>Thank you for doing whatever it was!</p>
> >
> > -- req/4 -----------------------------------
> > GET /wizard/1234/step1 HTTP/1.1
> > Accept: text/html
> >
> > -- res/4
> > HTTP/1.1 410 Gone
> > Content-Type: text/html
> >
> > <p>The wizard step does not exist anymore, because the thing was
> > finished.</p>
> >
> > snip ----------
> >
> > Of course, the entire thing needs to be implemented and is more
> > complex than just the simple resend solution.
> >
> > Robert
> >
> >
> > Am Freitag, den 10.06.2016, 15:11 -0600 schrieb Trenton D. Adams:
> > > That's just semantics though. For any statefulness to occur, a
> > > common token would be required. Whether that token is implicit
> > such
> > > as an IP, or crafted, such as a JSESSIONID, it's still a token
> > none
> > > the less. So I'm thinking the use of cookies, to send session
> > > tokens, isn't in keeping with REST principles.
> > >
> > > Let's take an example where someone is admitting to a university.
> > >
> > > 1. Page 1 contains biographical information, which the student
> > > submits.
> > > 2. Page 2 contains program/major information.
> > >
> > > In keeping with REST principles, you'd have to submit data from
> > page
> > > 1, and page 2, on page 2. Alternatively you could commit
> > information
> > > from page 1 to a database, and simply pass a student ID on page 2
> > > with the extra info on your program. Both would be in keeping
> > with
> > > REST principles. Storing page 1 info on the server side, and
> > passing
> > > just a cookie to identify the session on page 2, is NOT in
> > keeping
> > > with rest principles. Why? Because it's not scalable. You'd
> > have
> > > to specifically take action to make sure session state is copied
> > > between servers. There are technologies for that, but REST is
> > > intended to avoid the need. Hence transferring the entire state
> > from
> > > the client to the server on every request, not just a token for a
> > > session.
> > >
> > > Personally, I care very little about scalability. We're not
> > > facebook, twitter, etc. We would at most scale to 2-3 servers,
> > just
> > > for redundancy reasons, not load reasons. If I were to scale to
> > 1000
> > > servers, I'd want to start thinking about sticking very strictly
> > with
> > > REST principles.
> > >
> > > On Fri, Jun 10, 2016 at 2:44 PM, Robert Gacki <robert.gacki_at_conte
> > nttr
> > > ace.org> wrote:
> > > > Cookies in the scope of HTTP and REST are stateless. It is the
> > > > "Cookie"
> > > > header.
> > > >
> > > > The client and the server have to agree that data, that is sent
> > via
> > > > Cookie header, comprises a session that is relevant in
> > subsequent
> > > > requests (we call it then a "session").
> > > >
> > > > So Cookie is just a header and thus 100% stateless.
> > > >
> > > > Although, the cookie may be stored on the client and may be
> > send by
> > > > subsequent requests (following the RFC constraints about
> > domains
> > > > and
> > > > paths and expiry and all that stuff). And even this is
> > compliant
> > > > with
> > > > the REST principle.
> > > >
> > > > So if you use cookies, you are align with the REST principles.
> > > >
> > > > Robert
> > > >
> > > > Am Freitag, den 10.06.2016, 15:27 -0500 schrieb Tony Zakula:
> > > > > I would use what works and what is best for you. Standards
> > are
> > > > > great, but we do not have to be purists in everything we do
> > to
> > > > get
> > > > > work done. Jersey still runs on a servlet and you can easily
> > tap
> > > > > that session if you want to, nothing wrong with that. HTTP
> > that
> > > > REST
> > > > > is built on even supports cookies for the session. What is
> > wrong
> > > > > with mixing and matching a few pieces to make building your
> > app
> > > > > easy? Nothing. You can even support stateless and state on
> > the
> > > > same
> > > > > API calls with Jersey to satisfy different clients. Mobile
> > apps
> > > > may
> > > > > store state and web browsers do not. Offer both if needed.
> > Your
> > > > app
> > > > > will still work even if you do not adhere to the standard.
> > > > >
> > > > > In the end, build an app to fit your use case and that works
> > well
> > > > for
> > > > > you.
> > > > >
> > > > >
> > > > > On Fri, Jun 10, 2016 at 2:38 PM, Trenton D. Adams
> > <trenton.d.adam
> > > > s_at_gm
> > > > > ail.com> wrote:
> > > > > > Your descriptions of what REST is what I would like it to
> > be,
> > > > but
> > > > > > it isn't that, accrording to most everything I've read on
> > it.
> > > > If
> > > > > > you're storing state, you're not using REST. The use of
> > REST
> > > > > > precludes maintaing state server side. I'm tempted to use
> > JAX-
> > > > RS
> > > > > > regardless, and just not use the statelessness part.
> > > > > >
> > > > > > https://en.wikipedia.org/wiki/Representational_state_transf
> > er#S
> > > > tate
> > > > > > less
> > > > > > Stateless
> > > > > > See also: Stateless protocol
> > > > > > The client–server communication is further constrained by
> > no
> > > > client
> > > > > > context being stored on the server between requests. Each
> > > > request
> > > > > > from any client contains all the information necessary to
> > > > service
> > > > > > the request, and session state is held in the client. The
> > > > session
> > > > > > state can be transferred by the server to another service
> > such
> > > > as a
> > > > > > database to maintain a persistent state for a period and
> > allow
> > > > > > authentication. The client begins sending requests when it
> > is
> > > > ready
> > > > > > to make the transition to a new state. While one or more
> > > > requests
> > > > > > are outstanding, the client is considered to be in
> > transition.
> > > > The
> > > > > > representation of each application state contains links
> > that
> > > > may be
> > > > > > used the next time the client chooses to initiate a new
> > state-
> > > > > > transition.[12]
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 10, 2016 at 1:04 PM, Robert Gacki <robert.gacki
> > @con
> > > > tent
> > > > > > trace.org> wrote:
> > > > > > > Hi Trenton,
> > > > > > >
> > > > > > > I think, you misunderstand what REST is. REST is about
> > how a
> > > > > > > server and
> > > > > > > a client interacts to transfer state. The transport
> > itself is
> > > > > > > stateless
> > > > > > > ("dumb pipes"). It is an architectural style. The notion
> > of
> > > > state
> > > > > > > is
> > > > > > > something the client and server have to implement
> > themself.
> > > > What
> > > > > > > REST
> > > > > > > describes is nothing else what HTTP specifies, but is not
> > > > limited
> > > > > > > to
> > > > > > > HTTP (think of mail). In fact, Roy Fielding just took
> > HTTP as
> > > > an
> > > > > > > example for REST in his dissertation.
> > > > > > >
> > > > > > > OSI Layer
> > > > > > > ----------------------------------------------------
> > > > > > > | Your server and/or client application | L |
> > > > > > > ---------------------------------------------- a |
> > > > > > > | REST as architectural style | y 7 |
> > > > > > > ---------------------------------------------- e |
> > > > > > > | HTTP|MAIL|<other req / res based protocols>| r |
> > > > > > > ----------------------------------------------------
> > > > > > > Layer 6 and below
> > > > > > >
> > > > > > > JAX RS is only about modelling REST principles and Jersey
> > > > > > > provides the
> > > > > > > implementation. That does not include state management.
> > So
> > > > you
> > > > > > > should
> > > > > > > see JAX RS as the protocol toolset ("dumb pipes") to
> > build
> > > > > > > applications. What you call stateful is application state
> > and
> > > > > > > that is
> > > > > > > always application / implementation specific. For
> > example,
> > > > the
> > > > > > > notion
> > > > > > > of a session is purely application specific.
> > > > > > >
> > > > > > > So Jersey, at its core, does not provide you with
> > components
> > > > to
> > > > > > > build
> > > > > > > things like a wizard. But it provides you the ability to
> > > > build or
> > > > > > > use
> > > > > > > existing components, like JSR 371 and its
> > implementations.
> > > > > > >
> > > > > > > To your wizard example: You can solve wizards with
> > different
> > > > > > > methods.
> > > > > > > You described one solution, where the server does not
> > store
> > > > > > > results of
> > > > > > > previous wizard steps. Each solution has advantages and
> > > > > > > disadvantages.
> > > > > > > But all solutions have something in common: they are
> > > > application
> > > > > > > specific. If you use HTTP as a communication protocol,
> > you
> > > > can
> > > > > > > use REST
> > > > > > > principles to have a well-defined architectural style.
> > But
> > > > you
> > > > > > > still
> > > > > > > need to figure out how to maintain state between a
> > request
> > > > and
> > > > > > > response.
> > > > > > >
> > > > > > > An important part of REST is Hypermedia. For HTTP, this
> > is
> > > > just
> > > > > > > payload. For an application built by REST principles, it
> > is
> > > > the
> > > > > > > state
> > > > > > > that is transfered. And that state should include all
> > > > information
> > > > > > > necessary for server or client to support continous
> > > > interactions.
> > > > > > > If
> > > > > > > you use your browser and surf around, clicking on links
> > or
> > > > > > > signing in
> > > > > > > into your Google account, you are doing exactly what REST
> > > > > > > proposes for
> > > > > > > all other media types - not just HTML.
> > > > > > >
> > > > > > > So your wizard solution is based on HTML (a
> > representation)
> > > > and
> > > > > > > is
> > > > > > > constraint by the HTML specification and how browsers
> > behave.
> > > > > > > Thus, you
> > > > > > > may lose form field values when you use the browser's
> > back
> > > > > > > button. But
> > > > > > > you can do three things to counter that without storing
> > state
> > > > > > > server-
> > > > > > > side (outside request-response bounds): 1) You can
> > provide a
> > > > back
> > > > > > > button inside the form that just submits to the server -
> > the
> > > > > > > server
> > > > > > > renders the previous page with the values from the hidden
> > > > fields.
> > > > > > > 2) In
> > > > > > > modern browsers, with Javascript enabled, you can store
> > the
> > > > state
> > > > > > > client side and restore it when the user goes back. 3)
> > SPAs
> > > > > > > mostly
> > > > > > > avoid the problem by avoiding round-trips to the server,
> > with
> > > > the
> > > > > > > disadvantage of cloning lots of server-side logic for the
> > > > client
> > > > > > > (validation, business logic).
> > > > > > >
> > > > > > > Robert
> > > > > > >
> > > > > > >
> > > > > > > Am Freitag, den 10.06.2016, 12:11 -0600 schrieb Trenton
> > D.
> > > > Adams:
> > > > > > > > Thanks for the responses guys. I'm thinking more along
> > the
> > > > > > > lines of
> > > > > > > > JAX-RS implementations, such as Jersey, providing a
> > > > template
> > > > > > > based
> > > > > > > > approach, where the result can be served by JSP.
> > > > Technically,
> > > > > > > that's
> > > > > > > > almost useless when doing it statelessly, unless your
> > > > service
> > > > > > > is
> > > > > > > > intended to return HTML to a client program, or you
> > intend
> > > > to
> > > > > > > violate
> > > > > > > > the statelessness of REST. Cause like you say, writing
> > > > BBAs,
> > > > > > > is
> > > > > > > > actually quite tough without some nice statefulness.
> > > > > > > >
> > > > > > > > JSR 371 will be coming out too. Are they still
> > expecting
> > > > > > > stateless?
> > > > > > > > Cause it suddenly becomes less useful. Maintaining all
> > the
> > > > > > > state in
> > > > > > > > the browser's store is a lot of extra work, and just a
> > > > plain
> > > > > > > weird
> > > > > > > > way of dealing with it.
> > > > > > > >
> > > > > > > > On Fri, Jun 10, 2016 at 10:07 AM, <lenny_at_flowlogix.com>
> > > > wrote:
> > > > > > > > > Trenton, I feel your pain.
> > > > > > > > > In all honesty, the technology architecture didn’t
> > change
> > > > all
> > > > > > > that
> > > > > > > > > much in the last 10 years.
> > > > > > > > > Don’t get caught up in the Rest/Microservices hype
> > too
> > > > much.
> > > > > > > > > For BBAs (boring business apps) which I believe that
> > you
> > > > are
> > > > > > > > > dealing with (and I also like developing),
> > > > > > > > > it makes very little sense migrating to Rest-based
> > > > > > > architecture.
> > > > > > > > > Concentrate on cleaning, refactoring, modularizing
> > your
> > > > code,
> > > > > > > using
> > > > > > > > > the latest iterations of Java EE specs that you are
> > > > already
> > > > > > > using.
> > > > > > > > >
> > > > > > > > > So, why all the hype?
> > > > > > > > > Current Rest “state-of-the-art” today is actually in
> > it’s
> > > > > > > very
> > > > > > > > > infancy. It makes sense for some applications to do
> > it
> > > > > > > though, but
> > > > > > > > > not for BBAs.
> > > > > > > > > What apps does the Stateless Rest APIs make sense
> > for?
> > > > > > > > > - Multiple clients written separately by different
> > teams
> > > > > > > (i.e.
> > > > > > > > > native iOS, native Android, native JavaScript)
> > > > > > > > > - APIs that other companies use in different (non-
> > Java)
> > > > > > > languages
> > > > > > > > > - There are some other use cases also, but the above
> > are
> > > > the
> > > > > > > major
> > > > > > > > > ones
> > > > > > > > >
> > > > > > > > > What’s the negative impact of Rest services today, as
> > it
> > > > > > > relates to
> > > > > > > > > Java client and server development?
> > > > > > > > > - Massive violation of DRY principle, as it’s really
> > > > meant
> > > > > > > for
> > > > > > > > > client and server to be written in different
> > languages,
> > > > > > > > > i.e. client in JavaScript/iOS/Android and server in
> > Java
> > > > > > > > > - Data models are duplicated both in Java (on the
> > server)
> > > > and
> > > > > > > on
> > > > > > > > > the client (JS/iOS/Android)
> > > > > > > > > - Validation is duplicated on the client and server
> > > > > > > > > - Some business logic may need to be duplicated in
> > the
> > > > client
> > > > > > > and
> > > > > > > > > server
> > > > > > > > >
> > > > > > > > > The above negatives are something that are not solved
> > by
> > > > the
> > > > > > > > > industry quite yet, and for BBAs, (IMHO) is not worth
> > the
> > > > > > > effort.
> > > > > > > > >
> > > > > > > > > As far as answering your specific question, in “pure”
> > > > Rest
> > > > > > > API, All
> > > > > > > > > state is indeed handled by the client, including
> > > > > > > authentication.
> > > > > > > > > Authentication is usually handled by “bearer token”
> > > > paradigm,
> > > > > > > is
> > > > > > > > > sent with every request to the server, and thus re-
> > > > > > > authenticated by
> > > > > > > > > the server every time.
> > > > > > > > > Yes, it sounds (and is) a bit less efficient on per-
> > > > request
> > > > > > > basis
> > > > > > > > > (throughput per instance), but does (horizontally)
> > scale
> > > > > > > better to
> > > > > > > > > millions of users.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > On Jun 9, 2016, at 4:40 PM, Trenton D. Adams
> > > > <trenton.d.ada
> > > > > > > ms_at_gma
> > > > > > > > > > il.com> wrote:
> > > > > > > > > >
> > > > > > > > > > One thing I didn't mention, is that I'm considering
> > > > > > > updating one
> > > > > > > > > > of our enterprise apps to more modern technologies,
> > > > where
> > > > > > > it
> > > > > > > > > > actually saves effort. It is currently based on
> > RMI,
> > > > with
> > > > > > > a
> > > > > > > > > > custom web front-end/mvc framework based on a the
> > > > command
> > > > > > > > > > pattern. So, I'm trying to determine whether we
> > should
> > > > do
> > > > > > > EJB or
> > > > > > > > > > JAX-RS for the back-end, and possibly JAX-RS for
> > the
> > > > front
> > > > > > > end.
> > > > > > > > > > One of the issues is that EJB is almost a drop in
> > > > > > > replacement for
> > > > > > > > > > RMI. It would require significant more effort to
> > > > switch to
> > > > > > > JAX-
> > > > > > > > > > RS.
> > > > > > > > > >
> > > > > > > > > > When the back end is stateless, it's simply pushing
> > the
> > > > > > > > > > complexity to the client. It is now the client
> > that
> > > > must
> > > > > > > do all
> > > > > > > > > > the work to know what it needs to send; i.e. it
> > keeps
> > > > it's
> > > > > > > own
> > > > > > > > > > state. For the back end, that's HIGHLY scale-able
> > > > > > > technology
> > > > > > > > > > wise, but has other drawbacks. With a stateful
> > back-
> > > > end,
> > > > > > > you
> > > > > > > > > > just set the firstname, lastname, birthdate, etc,
> > and
> > > > pass
> > > > > > > around
> > > > > > > > > > a reference to the back-end object, such as with
> > EJB.
> > > > > > > Neither
> > > > > > > > > > the front end nor the back end have to maintain
> > much
> > > > state,
> > > > > > > > > > programmatically speaking; it's the service that
> > does
> > > > that
> > > > > > > (EJB
> > > > > > > > > > for example). This saves developer time, does it
> > not?
> > > > > > > > > >
> > > > > > > > > > It seems that using the html5 stuff would be a pain
> > in
> > > > the
> > > > > > > butt.
> > > > > > > > > > Mainly because html5's storage system can't store a
> > > > > > > javascript
> > > > > > > > > > object even, so you can't even abstract your data
> > > > storage.
> > > > > > > Plus,
> > > > > > > > > > we'd end up not supporting people with older
> > > > > > > machines/browsers.
> > > > > > > > > > And then, if you have a series of web pages that a
> > > > person
> > > > > > > is
> > > > > > > > > > going through, you'd have to write code to grab all
> > of
> > > > > > > that, and
> > > > > > > > > > pass it to the server.
> > > > > > > > > >
> > > > > > > > > > So, should I not use JAX-RS if I'm wanting to
> > maintain
> > > > > > > state? I
> > > > > > > > > > mean it kind of goes against the "ST" in REST.
> > Nothing
> > > > > > > actually
> > > > > > > > > > prevents you from maintaining state though.
> > > > > > > > > >
> > > > > > > > > > I've read some articles where people say you
> > shouldn't
> > > > even
> > > > > > > be
> > > > > > > > > > maintaining state of authentication. That I don't
> > > > agree
> > > > > > > with,
> > > > > > > > > > because some services don't even have access to the
> > > > user's
> > > > > > > > > > credentials. So at some point, someone is going to
> > > > have to
> > > > > > > > > > maintain state. So, you could either not use JAX-
> > RS,
> > > > or
> > > > > > > use it
> > > > > > > > > > and maintain state while doing so, but essentially
> > > > violate
> > > > > > > it's
> > > > > > > > > > principles.
> > > > > > > > > >
> > > > > > > > > > Also, doesn't statelessness become very complex
> > when
> > > > you
> > > > > > > have
> > > > > > > > > > larger enterprise applications?
> > > > > > > > > >
> > > > > > > > > > I see a lot of benefits of JAX-RS, and a lot of
> > > > drawbacks.
> > > > > > > Am I
> > > > > > > > > > missing something?
> > > > > > > > > >
> > > > > > > > > > On Wed, Jun 8, 2016 at 5:46 PM, cowwoc <cowwoc_at_bbs.
> > dark
> > > > tech
> > > > > > > .org>
> > > > > > > > > > wrote:
> > > > > > > > > > > Define "application logic".
> > > > > > > > > > >
> > > > > > > > > > > In the case you mentioned below (storing the
> > user's
> > > > last
> > > > > > > name
> > > > > > > > > > > somewhere) I would favor using localStorage and
> > > > > > > sessionStore to
> > > > > > > > > > > store this information: http://www.w3schools.com/
> > html
> > > > /htm
> > > > > > > l5_web
> > > > > > > > > > > storage.asp
> > > > > > > > > > > The client would read the information from the
> > local
> > > > > > > store and
> > > > > > > > > > > use it to make AJAX calls.
> > > > > > > > > > >
> > > > > > > > > > > I misspoke earlier when I talked about Cookies.
> > These
> > > > are
> > > > > > > > > > > typically used to reference to a server-side
> > state
> > > > that
> > > > > > > is
> > > > > > > > > > > present across all calls. If some REST calls need
> > one
> > > > > > > piece of
> > > > > > > > > > > information and others need another, I would pull
> > > > them
> > > > > > > from the
> > > > > > > > > > > local/sessionStore and pass them to the AJAX
> > calls as
> > > > > > > needed.
> > > > > > > > > > >
> > > > > > > > > > > Gili
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 2016-06-08 7:40 PM, Trenton D. Adams wrote:
> > > > > > > > > > > > So are you saying push all the application
> > logic to
> > > > the
> > > > > > > > > > > > browser, using javascript? Are cookies really
> > > > intended
> > > > > > > to
> > > > > > > > > > > > store a whole bunch of user data?
> > > > > > > > > > > >
> > > > > > > > > > > > I know with HTML5, you can use
> > > > > > > > > > > > sessionStorage.setItem("lastname", "last
> > name").
> > > > But,
> > > > > > > I
> > > > > > > > > > > > don't think moving most application logic into
> > a
> > > > > > > browser is
> > > > > > > > > > > > very maintainable, maybe I'm wrong though.
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Jun 8, 2016 at 5:29 PM, cowwoc <cowwoc@
> > bbs.
> > > > dark
> > > > > > > tech.o
> > > > > > > > > > > > rg> wrote:
> > > > > > > > > > > > > Without commenting on the specifics of
> > Jersey, I
> > > > > > > agree:
> > > > > > > > > > > > > REST is for computers, not humans.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I typically expose REST APIs for computers
> > and
> > > > use
> > > > > > > cookies
> > > > > > > > > > > > > to maintain browser sessions. The browser can
> > > > then
> > > > > > > read
> > > > > > > > > > > > > stateful information from the Cookie and
> > serve it
> > > > to
> > > > > > > > > > > > > stateless REST APIs. Not all clients are web-
> > > > > > > browsers, so
> > > > > > > > > > > > > your REST API should be designed around non-
> > > > browsers.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Gili
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 2016-06-08 5:58 PM, Trenton D. Adams
> > wrote:
> > > > > > > > > > > > > > Good day,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm a bit confused. I actually have two
> > > > separate
> > > > > > > > > > > > > > questions. I understand that REST is
> > supposed
> > > > to
> > > > > > > be done
> > > > > > > > > > > > > > in a stateless way. For regular web
> > services
> > > > > > > that's
> > > > > > > > > > > > > > easy. I mean it really shifts a lot of the
> > > > work to
> > > > > > > the
> > > > > > > > > > > > > > client, where it seems to be more difficult
> > to
> > > > deal
> > > > > > > with,
> > > > > > > > > > > > > > but as far as the server goes, it's simple.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > However, how is it even possible to use
> > jersey
> > > > > > > templates
> > > > > > > > > > > > > > without state (sessions), in a reasonable
> > way?
> > > > The
> > > > > > > > > > > > > > browser isn't going to maintain the state.
> > It
> > > > > > > seems that
> > > > > > > > > > > > > > one would need to make sure each and every
> > page
> > > > > > > puts
> > > > > > > > > > > > > > hidden inputs from the previous form, in
> > the
> > > > html
> > > > > > > output,
> > > > > > > > > > > > > > so that it is re-submitted with the new
> > > > request.
> > > > > > > That
> > > > > > > > > > > > > > would be a lot of work. If the user
> > presses
> > > > the
> > > > > > > back
> > > > > > > > > > > > > > button, all that state vanishes, and the
> > user
> > > > must
> > > > > > > re-
> > > > > > > > > > > > > > enter any screens they go forward to
> > again.
> > > > This
> > > > > > > doesn't
> > > > > > > > > > > > > > make for a very good user experience.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Can someone explain to me how the use of
> > JAX-RS
> > > > as
> > > > > > > an MVC
> > > > > > > > > > > > > > framework is even possible in a reasonable
> > way,
> > > > > > > while
> > > > > > > > > > > > > > being stateless?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Then, can someone explain to me how
> > > > statelessness
> > > > > > > in a
> > > > > > > > > > > > > > back-end REST web service, promotes good
> > code
> > > > > > > design,
> > > > > > > > > > > > > > where user interaction is a necessity? It
> > > > seems to
> > > > > > > me
> > > > > > > > > > > > > > that the client would then need to maintain
> > all
> > > > the
> > > > > > > > > > > > > > state, thereby tightly coupling all the
> > data
> > > > points
> > > > > > > > > > > > > > between the different controllers on the
> > > > client.
> > > > > > > > > > > > > > Something like EJB allows you to pass
> > around
> > > > the
> > > > > > > stateful
> > > > > > > > > > > > > > pointer, and you simply add data as you go.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > After reading this stack exchange post,
> > it's
> > > > > > > sounding
> > > > > > > > > > > > > > like everyone thinks that REST is NOT for
> > > > users,
> > > > > > > but for
> > > > > > > > > > > > > > services only.
> > > > > > > > > > > > > > http://stackoverflow.com/questions/3105296/
> > if-r
> > > > est-
> > > > > > > applic
> > > > > > > > > > > > > > ations-are-supposed-to-be-stateless-how-do-
> > you-
> > > > > > > manage-
> > > > > > > > > > > > > > sessions
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I understand that it's more scalable, as
> > the
> > > > server
> > > > > > > > > > > > > > always knows exactly what you want, because
> > > > you're
> > > > > > > > > > > > > > telling it every time. But it seems like
> > that
> > > > > > > would come
> > > > > > > > > > > > > > with a lot more boilerplate coding.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >