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.
>> >>>
>> >>>
>> >>
>> >>
>> >
>
>