By state, I simply mean that the server maintains the object instances in
use, and responds to calls to them. I've found that using state in such
ways, such as RMI or EJB, makes development a lot easier. I'm trying to
find out if I'm missing something on that.
On Thu, Jun 9, 2016 at 3:59 PM, Martynas Jusevičius <martynas_at_graphity.org>
wrote:
> Can you clarify what "state" you are talking about? For
> authentication/authorization, you can use HTTP headers. What else?
>
> To me, REST is more about query and change of state, not state as such.
>
> I presented paper recently on a similar topic (Linked Data), maybe
> you'll find it interesting:
>
> https://github.com/AtomGraph/Linked-Data-Templates/tree/master/XML%20London%202016%20paper
>
> On Thu, Jun 9, 2016 at 11:40 PM, Trenton D. Adams
> <trenton.d.adams_at_gmail.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.darktech.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/html5_webstorage.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_at_bbs.darktech.org> 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-rest-applications-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.
> >>>
> >>>
> >>
> >>
> >
>