What do you mean get rid of the object layer? So you're using C style
structured programming now?
On Thu, Jun 9, 2016 at 4:19 PM, Martynas Jusevičius <martynas_at_graphity.org>
wrote:
> A solution that worked great for us was to get rid of the object layer
> altogether :)
>
> On Fri, Jun 10, 2016 at 12:06 AM, Trenton D. Adams
> <trenton.d.adams_at_gmail.com> wrote:
> > 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.
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >
> >
>