stateless REST

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

stateless REST

Trenton D. Adams
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.

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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

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

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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Trenton D. Adams
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 <[hidden email]> 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.

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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Gili
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 <[hidden email]> 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.

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.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Trenton D. Adams
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 <[hidden email]> 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 <[hidden email]> 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.

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.





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Martynas Jusevičius-2
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
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
>>>
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Martynas Jusevičius
In reply to this post by Trenton D. Adams
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
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
>>>
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Trenton D. Adams
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 <[hidden email]> 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
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
>>>
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Martynas Jusevičius
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
<[hidden email]> 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 <[hidden email]>
> 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
>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
>> >>>
>> >>>
>> >>
>> >>
>> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Trenton D. Adams
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 <[hidden email]> 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
<[hidden email]> 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 <[hidden email]>
> 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
>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
>> >>>
>> >>>
>> >>
>> >>
>> >
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Gili
In reply to this post by Trenton D. Adams
JAX-RS != REST. It is one possible implementation of it and it has its flaws.

Having worked with REST heavily over the past couple of years I would say that it is always a lot more work than you'd expect up-front for the server implementer but that it is actually a pleasure to use from the client perspective. Of course, this assumes that your REST API is well-designed, which is actually quite difficult to do.

The main advantages of REST, as I understand it, is that it is far more scalable and technology-agnostic than the alternatives.

Most people don't need either of those things (how many of you are building the next Facebook? Trust me, you're not) but it's a nice goal to strive for.

Gili

On 2016-06-09 5:40 PM, Trenton D. Adams 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 <[hidden email]> 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 <[hidden email]> 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.

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.






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Trenton D. Adams
Yes, the idea of scalability.  As far as serving our users, we don't even need scale-able.  The only time we need scalability, is when we're concerned with availability.  And then, you only need 2-3 server instances per service.

And yes, I can see it being difficult to design the rest service well.  There's a whole heck of a lot to thinking involved.  Everything from properly using HTTP, to picking uniform paths and what not.  It would require some thought, and unfortunately, a lot of developers would rather just start writing code.

On Thu, Jun 9, 2016 at 7:11 PM, cowwoc <[hidden email]> wrote:
JAX-RS != REST. It is one possible implementation of it and it has its flaws.

Having worked with REST heavily over the past couple of years I would say that it is always a lot more work than you'd expect up-front for the server implementer but that it is actually a pleasure to use from the client perspective. Of course, this assumes that your REST API is well-designed, which is actually quite difficult to do.

The main advantages of REST, as I understand it, is that it is far more scalable and technology-agnostic than the alternatives.

Most people don't need either of those things (how many of you are building the next Facebook? Trust me, you're not) but it's a nice goal to strive for.

Gili


On 2016-06-09 5:40 PM, Trenton D. Adams 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 <[hidden email]> 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 <[hidden email][hidden email]> 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.

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.







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Robert Gacki
In reply to this post by Gili
Hi,

JAX-RS is a specification, not an implementation. JAX-RS defines how a
Java application can provide endpoints that follow REST principles. And
I don't see any big flaws in the specification. If it had big flaws, it
would have never been accepted as a JSR and never found its way into
Java EE.

Well, there are some things that can be improved (e.g. features for
navigation and linking). But that could easily lead to overengineering
of that specification. So its a good thing that its kept at a basic
level. And there are lots of libraries that extend Jersey / RestEasy /
* to provide more sugar.

You also said that REST is for computers, not humans. Sorry, but that
is just wrong. REST describes the basic principles of how the web
works. It was created at a time, where HTML clients were the common
kind of client to use HTTP. Fielding just explained that HTTP allows
other kinds of clients. This includes clients for humans and for
automation.

Robert


Am Donnerstag, den 09.06.2016, 21:11 -0400 schrieb cowwoc:

> JAX-RS != REST. It is one possible implementation of it and it has
> its flaws.
>
> Having worked with REST heavily over the past couple of years I would
> say that it is always a lot more work than you'd expect up-front for
> the server implementer but that it is actually a pleasure to use from
> the client perspective. Of course, this assumes that your REST API is
> well-designed, which is actually quite difficult to do.
>
> The main advantages of REST, as I understand it, is that it is far
> more scalable and technology-agnostic than the alternatives.
>
> Most people don't need either of those things (how many of you are
> building the next Facebook? Trust me, you're not) but it's a nice
> goal to strive for.
>
> Gili
>
> On 2016-06-09 5:40 PM, Trenton D. Adams 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 <[hidden email]>
> > 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_webst
> > > orage.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 <[hidden email]
> > > > > 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-applicat
> > > > > > ions-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.
> > > > > >
> > > > >
> > >
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

TonyZ
You can use the REST pattern and still maintain state on the server if you wish instead of the client.  You can mix and match even.  It all just depends on how you design your what is behind your REST endpoints.  If you do not get too caught up in trying to adhere to everything everyone thinks REST should be, it is really quite flexible.


On Fri, Jun 10, 2016 at 3:33 AM, Robert Gacki <[hidden email]> wrote:
Hi,

JAX-RS is a specification, not an implementation. JAX-RS defines how a
Java application can provide endpoints that follow REST principles. And
I don't see any big flaws in the specification. If it had big flaws, it
would have never been accepted as a JSR and never found its way into
Java EE.

Well, there are some things that can be improved (e.g. features for
navigation and linking). But that could easily lead to overengineering
of that specification. So its a good thing that its kept at a basic
level. And there are lots of libraries that extend Jersey / RestEasy /
* to provide more sugar.

You also said that REST is for computers, not humans. Sorry, but that
is just wrong. REST describes the basic principles of how the web
works. It was created at a time, where HTML clients were the common
kind of client to use HTTP. Fielding just explained that HTTP allows
other kinds of clients. This includes clients for humans and for
automation.

Robert


Am Donnerstag, den 09.06.2016, 21:11 -0400 schrieb cowwoc:
> JAX-RS != REST. It is one possible implementation of it and it has
> its flaws.
>
> Having worked with REST heavily over the past couple of years I would
> say that it is always a lot more work than you'd expect up-front for
> the server implementer but that it is actually a pleasure to use from
> the client perspective. Of course, this assumes that your REST API is
> well-designed, which is actually quite difficult to do.
>
> The main advantages of REST, as I understand it, is that it is far
> more scalable and technology-agnostic than the alternatives.
>
> Most people don't need either of those things (how many of you are
> building the next Facebook? Trust me, you're not) but it's a nice
> goal to strive for.
>
> Gili
>
> On 2016-06-09 5:40 PM, Trenton D. Adams 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 <[hidden email]>
> > 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_webst
> > > orage.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 <[hidden email]
> > > > > 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-applicat
> > > > > > ions-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.
> > > > > >
> > > > >
> > >

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Gili
In reply to this post by Robert Gacki
On 2016-06-10 4:33 AM, Robert Gacki wrote:
> You also said that REST is for computers, not humans. Sorry, but that
> is just wrong. REST describes the basic principles of how the web
> works. It was created at a time, where HTML clients were the common
> kind of client to use HTTP. Fielding just explained that HTTP allows
> other kinds of clients. This includes clients for humans and for
> automation.

My point was that humans do not interact with a REST server directly.
They always go through an intermediary (a web browser in most cases)
that submits HTTP requests on their behalf.

Humans expect a stateful conversation with the server. REST mandates a
stateless conversation. The browser abstracts this implementation-detail
away from the human.

Gili
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Robert Gacki
What do you mean by directly? What is direct? I count using a browser
as direct interaction with a server, that serves me webpages or a
download. HTTP itself is just a protocol that is mostly human-readable
- a reason for why its so successful and easy to adopt.

The 'stateless' _only_ refers to HTTP or HTTP-like protocols (like e-
mail). Maintaining state between server and client is the
responsibility of the client and server application. Because of that,
Fielding explains things like idempotence or what HTTP verbs are
responsible for. It is often summarized as "Dump pipes, smart clients".

To summarize it in my words: So the transport layer is stateless, the
application layer may maintain state.

Robert

Am Freitag, den 10.06.2016, 10:34 -0400 schrieb cowwoc:

> On 2016-06-10 4:33 AM, Robert Gacki wrote:
> >
> > You also said that REST is for computers, not humans. Sorry, but
> > that
> > is just wrong. REST describes the basic principles of how the web
> > works. It was created at a time, where HTML clients were the common
> > kind of client to use HTTP. Fielding just explained that HTTP
> > allows
> > other kinds of clients. This includes clients for humans and for
> > automation.
> My point was that humans do not interact with a REST server
> directly. 
> They always go through an intermediary (a web browser in most cases) 
> that submits HTTP requests on their behalf.
>
> Humans expect a stateful conversation with the server. REST mandates
> a 
> stateless conversation. The browser abstracts this implementation-
> detail 
> away from the human.
>
> Gili
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Robert Gacki
Dum_b_ pipes, smart clients.

Akward. ;)

Robert

Am Freitag, den 10.06.2016, 17:30 +0200 schrieb Robert Gacki:

> What do you mean by directly? What is direct? I count using a browser
> as direct interaction with a server, that serves me webpages or a
> download. HTTP itself is just a protocol that is mostly human-
> readable
> - a reason for why its so successful and easy to adopt.
>
> The 'stateless' _only_ refers to HTTP or HTTP-like protocols (like e-
> mail). Maintaining state between server and client is the
> responsibility of the client and server application. Because of that,
> Fielding explains things like idempotence or what HTTP verbs are
> responsible for. It is often summarized as "Dump pipes, smart
> clients".
>
> To summarize it in my words: So the transport layer is stateless, the
> application layer may maintain state.
>
> Robert
>
> Am Freitag, den 10.06.2016, 10:34 -0400 schrieb cowwoc:
> >
> > On 2016-06-10 4:33 AM, Robert Gacki wrote:
> > >
> > >
> > > You also said that REST is for computers, not humans. Sorry, but
> > > that
> > > is just wrong. REST describes the basic principles of how the web
> > > works. It was created at a time, where HTML clients were the
> > > common
> > > kind of client to use HTTP. Fielding just explained that HTTP
> > > allows
> > > other kinds of clients. This includes clients for humans and for
> > > automation.
> > My point was that humans do not interact with a REST server
> > directly. 
> > They always go through an intermediary (a web browser in most
> > cases) 
> > that submits HTTP requests on their behalf.
> >
> > Humans expect a stateful conversation with the server. REST
> > mandates
> > a 
> > stateless conversation. The browser abstracts this implementation-
> > detail 
> > away from the human.
> >
> > Gili
> >
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Lenny Primak
In reply to this post by Trenton D. Adams
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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.






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

Lenny Primak-2
In reply to this post by Trenton D. Adams
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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.







signature.asc (506 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: stateless REST

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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

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.







123
Loading...