users@jersey.java.net

[Jersey] Re: stateless REST

From: Trenton D. Adams <trenton.d.adams_at_gmail.com>
Date: Mon, 13 Jun 2016 02:57:05 -0600

Well, we've offloaded that to the provider, by directing the student to
their pages for credit card related activities. But, it's the state of it
all that needs to be maintained somewhere. Obviously if I switched to
REST, that state would be in the ERP in some schema somewhere.

On Mon, Jun 13, 2016 at 2:54 AM, Robert Gacki <robert.gacki_at_contenttrace.org
> wrote:

> PCI DSS compliance is painful. I wish you success.
>
> Am Montag, den 13.06.2016, 02:51 -0600 schrieb Trenton D. Adams:
> > Yes, that's what I thought you implied. I've considered that in
> > thinking through this. The only problem is the very large amounts of
> > work that such a think would entail.
> >
> > Also, when the students finally hit the credit card screen, we then
> > also have to store that state as well, which is yet another pain in
> > the butt.
> >
> > On Mon, Jun 13, 2016 at 2:40 AM, Robert Gacki <robert.gacki_at_contenttr
> > ace.org> wrote:
> > > You should consider denormalization. For lots of things, we just
> > > store
> > > JSON in our database, because we don't need to query that data
> > > directly. The tables you create should only have this one purpose
> > > and
> > > nothing else: support your data collection. You could even use
> > > another
> > > database, like Redis. If the resources only exist for a short
> > > period of
> > > time (until the data collection is finished), the database may even
> > > have lower SLAs than your ERP.
> > >
> > > Robert
> > >
> > > Am Montag, den 13.06.2016, 02:33 -0600 schrieb Trenton D. Adams:
> > > > Yes, I could create our own tables in the database, for the
> > > > preliminary data, and later do the PL/SQL calls to move that data
> > > > into the real tables. But, that's a HUGE undertaking. It very
> > > much
> > > > seems like converting from RMI to EJB would be the ideal way to
> > > go.
> > > >
> > > > Are you keeping authenticated state at least?
> > > >
> > > > On Mon, Jun 13, 2016 at 2:13 AM, Robert Gacki <robert.gacki_at_conte
> > > nttr
> > > > ace.org> wrote:
> > > > > You can always create resources on the server. So just create
> > > > > resources
> > > > > for your data collection. And if that data collection is
> > > finished,
> > > > > you
> > > > > ask the server to compile that data in whatever you want.
> > > That's
> > > > > 100%
> > > > > possible in a REST approach.
> > > > >
> > > > > For instance, we have a checkout in our platform that requires
> > > > > various
> > > > > data to be provided by the user. First we create the checkout
> > > > > resource.
> > > > > And the the client can do subsequent requests to add / update
> > > more
> > > > > data. And finally, the user can complete the checkout. This
> > > entire
> > > > > thing is stateless in terms of communication and the resource
> > > > > model.
> > > > > >From the application perspective, there is state that has to
> > > > > revalidated with each request / response.
> > > > >
> > > > > Yes, if you have a complex data model, you probably have to
> > > invest
> > > > > into
> > > > > the implementation. But you have that complexity in the first
> > > > > place.
> > > > >
> > > > > Robert
> > > > >
> > > > >
> > > > > Am Montag, den 13.06.2016, 01:46 -0600 schrieb Trenton D.
> > > Adams:
> > > > > > That seems like a utopian view though. With an existing
> > > system
> > > > > you
> > > > > > need to use, such as an ERP, architecting your system to be
> > > > > stateless
> > > > > > could involve huge amounts of work. Ultimately, if a person
> > > is
> > > > > > really religious about not maintaining state, they would have
> > > to
> > > > > > store state in the browser only. But then, if you have an
> > > > > existing
> > > > > > app, you must completely redesign it to do that, all in one
> > > > > shot.
> > > > > > That's not really easy to do with decent sized applications.
> > > > > >
> > > > > > On Fri, Jun 10, 2016 at 5:24 PM, Martynas Jusevičius <martyna
> > > s_at_at
> > > > > omgr
> > > > > > aph.com> wrote:
> > > > > > > The component that keeps the state server-side it the
> > > > > persistent
> > > > > > > store. Besides that, it is not necessary to keep any state
> > > in
> > > > > the
> > > > > > > object layer which is client-specifing or spanning request.
> > > All
> > > > > > > processing should be done per-request, using request body
> > > and
> > > > > > > headers
> > > > > > > only. If it is a GET request, state is queried from the
> > > > > permanent
> > > > > > > store, otherwise state is change in it.
> > > > > > >
> > > > > > > HTTP and REST hypermedia define a uniform protocol, URIs
> > > are
> > > > > > > uniform
> > > > > > > identifiers. The last piece of a uniform hypermedia API:
> > > RDF,
> > > > > > > uniform
> > > > > > > data model. We've designed an approach that combines these
> > > > > > > technologies and enables a single, generic read-write web
> > > API:
> > > > > > > https://github.com/AtomGraph/Linked-Data-Templates/tree/mas
> > > ter/
> > > > > XML%
> > > > > > > 20London%202016%20paper
> > > > > > >
> > > > > > >
> > > > > > > Martynas
> > > > > > > atomgraph.com
> > > > > > >
> > > > > > > On Sat, Jun 11, 2016 at 12:13 AM, Trenton D. Adams
> > > > > > > <trenton.d.adams_at_gmail.com> wrote:
> > > > > > > > Hi Jason,
> > > > > > > >
> > > > > > > > Thanks for the response.
> > > > > > > >
> > > > > > > > So, you're using REST, but not maintaining state server
> > > side,
> > > > > > > yes? i.e. no
> > > > > > > > sessions. So, when you can't commit data to a database,
> > > > > until
> > > > > > > all of the
> > > > > > > > data is obtained, in your experience, how do you maintain
> > > > > that
> > > > > > > data until
> > > > > > > > the process is complete?
> > > > > > > >
> > > > > > > > Do you use HTML5 session storage?
> > > > > > > >
> > > > > > > > Do you not use JAX-RS for user responses (e.g. Jersey
> > > > > templates)?
> > > > > > > >
> > > > > > > > I'm curious. Partly because it seems like a lot of work
> > > to
> > > > > not
> > > > > > > have the
> > > > > > > > server maintain state. When the server maintains state,
> > > I
> > > > > can
> > > > > > > set all
> > > > > > > > variables from page 1 to page n on the server side, and
> > > use
> > > > > only
> > > > > > > a reference
> > > > > > > > to that object, and continue doing so until I'm complete,
> > > and
> > > > > I
> > > > > > > commit.
> > > > > > > > This is what makes EJB look so good to me.
> > > > > > > >
> > > > > > > > On Fri, Jun 10, 2016 at 3:55 PM, Jason Lee <jason_at_steeple
> > > soft
> > > > > .com
> > > > > > > > wrote:
> > > > > > > >>
> > > > > > > >> I don't think that's a true statement ("The use of REST
> > > > > > > precludes
> > > > > > > >> maintaining state server side"). Of course the server-
> > > side
> > > > > > > maintains state:
> > > > > > > >> it has to have SOMETHING to transfer to the client,
> > > right?
> > > > > :)
> > > > > > > What the
> > > > > > > >> server-side should NOT do, in a pure RESTful
> > > architecture,
> > > > > is
> > > > > > > store some
> > > > > > > >> sort of client-specific state such as we might be used
> > > to
> > > > > used
> > > > > > > to doing with
> > > > > > > >> session-scoped beans in, say, a JSF application. In
> > > other
> > > > > > > words, it
> > > > > > > >> shouldn't have the notion of a client's *session*
> > > (including
> > > > > > > things like a
> > > > > > > >> client's current step in a wizard), but it certainly
> > > needs
> > > > > > > *state* ("no
> > > > > > > >> client context being stored on the server between
> > > > > requests").
> > > > > > > >>
> > > > > > > >> To address the "where to put the application logic"
> > > question
> > > > > > > from earlier
> > > > > > > >> in the thread, the server can (and should! :) react when
> > > the
> > > > > > > state changes
> > > > > > > >> in certain ways to perform system-specific processing.
> > > For
> > > > > > > example, the
> > > > > > > >> client updates the state of an Order entity to, say,
> > > > > SUBMITTED,
> > > > > > > the server
> > > > > > > >> notices this change (through means that aren't relevant
> > > > > here),
> > > > > > > and begins
> > > > > > > >> some sort of processing in the background.
> > > > > > > >>
> > > > > > > >> Moving all of the app's logic to the client is probably
> > > not
> > > > > a
> > > > > > > wise move
> > > > > > > >> for a number of reasons, though there will almost
> > > certainly
> > > > > be
> > > > > > > SOME logic
> > > > > > > >> there, such as validation, page flow coordination, etc.
> > > > > > > >>
> > > > > > > >> Having said all of that, we've tended to be pretty
> > > pragmatic
> > > > > on
> > > > > > > the
> > > > > > > >> systems I've worked on, adhering as strictly as possible
> > > to
> > > > > > > Fielding's
> > > > > > > >> notions, but deviating, grudgingly, when it made sense
> > > to do
> > > > > so
> > > > > > > (i.e., a
> > > > > > > >> strictly RESTful implementation would make the APIs
> > > usage
> > > > > slow,
> > > > > > > chatty,
> > > > > > > >> cumbersome, etc). For example, for authentication, one
> > > > > system
> > > > > > > had an
> > > > > > > >> endpoint to authenticate a user that would return an
> > > auth
> > > > > token
> > > > > > > (it might
> > > > > > > >> actually have been called a session ID :) that
> > > subsequent
> > > > > calls
> > > > > > > would then
> > > > > > > >> send in lieu of credentials. This was done, in part, so
> > > that
> > > > > if
> > > > > > > the token
> > > > > > > >> were intercepted and used, all that would be exposed to
> > > an
> > > > > > > attacker is that
> > > > > > > >> session and not the user's credentials (SSL helps, of
> > > > > course).
> > > > > > > >>
> > > > > > > >> Oh, and if I'm ever asked to implement HATEOAS again,
> > > I'll
> > > > > be
> > > > > > > tempted to
> > > > > > > >> rage quit. That was a terrible experience. :)
> > > > > > > >>
> > > > > > > >> At any rate, history (and personal experience ;) shows
> > > you
> > > > > CAN
> > > > > > > build
> > > > > > > >> complex applications with JAX-RS, but you do have to
> > > change
> > > > > how
> > > > > > > you think
> > > > > > > >> about designing the system.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> On 6/10/16 2:38 PM, Trenton D. Adams 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_tra
> > > nsfe
> > > > > r#St
> > > > > > > ateless
> > > > > > > >> 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_at_contenttrace.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.co
> > > m>
> > > > > > > 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.a
> > > > > > > dams_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_bb
> > > s.da
> > > > > rkte
> > > > > > > ch.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.co
> > > m/ht
> > > > > ml/h
> > > > > > > tml5_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 <cowwo
> > > c_at_bb
> > > > > s.da
> > > > > > > rktech.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/310529
> > > 6/if
> > > > > -res
> > > > > > > t-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.
> > > > > > > >>> > > > > > > >
> > > > > > > >>> > > > > > >
> > > > > > > >>> > > > >
> > > > > > > >>> > >
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> Jason Lee
> > > > > > > >> http://cubtracker.com
> > > > > > > >> http://blogs.steeplesoft.com
> > > > > > > >> http://twitter.com/jasondlee
> > > > > > > >> http://blogs.steeplesoft.com/+
> > > > > > > >> http://blogs.steeplesoft.com/in
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
>