Define "application logic".
In the case you mentioned below (storing the user's last name somewhere)
I would favor using localStorage and sessionStore to store this
information:
http://www.w3schools.com/html/html5_webstorage.asp
The client would read the information from the local store and use it to
make AJAX calls.
I misspoke earlier when I talked about Cookies. These are typically used
to reference to a server-side state that is present across all calls. If
some REST calls need one piece of information and others need another, I
would pull them from the local/sessionStore and pass them to the AJAX
calls as needed.
Gili
On 2016-06-08 7:40 PM, Trenton D. Adams wrote:
> So are you saying push all the application logic to the browser, using
> javascript? Are cookies really intended to store a whole bunch of
> user data?
>
> I know with HTML5, you can use sessionStorage.setItem("lastname",
> "last name"). But, I don't think moving most application logic into a
> browser is very maintainable, maybe I'm wrong though.
>
> On Wed, Jun 8, 2016 at 5:29 PM, cowwoc <cowwoc_at_bbs.darktech.org
> <mailto:cowwoc_at_bbs.darktech.org>> wrote:
>
> Without commenting on the specifics of Jersey, I agree: REST is
> for computers, not humans.
>
> I typically expose REST APIs for computers and use cookies to
> maintain browser sessions. The browser can then read stateful
> information from the Cookie and serve it to stateless REST APIs.
> Not all clients are web-browsers, so your REST API should be
> designed around non-browsers.
>
> Gili
>
>
> On 2016-06-08 5:58 PM, Trenton D. Adams wrote:
>> Good day,
>>
>> I'm a bit confused. I actually have two separate questions. I
>> understand that REST is supposed to be done in a stateless way.
>> For regular web services that's easy. I mean it really shifts a
>> lot of the work to the client, where it seems to be more
>> difficult to deal with, but as far as the server goes, it's simple.
>>
>> However, how is it even possible to use jersey templates without
>> state (sessions), in a reasonable way? The browser isn't going to
>> maintain the state. It seems that one would need to make sure
>> each and every page puts hidden inputs from the previous form, in
>> the html output, so that it is re-submitted with the new
>> request. That would be a lot of work. If the user presses the
>> back button, all that state vanishes, and the user must re-enter
>> any screens they go forward to again. This doesn't make for a
>> very good user experience.
>>
>> Can someone explain to me how the use of JAX-RS as an MVC
>> framework is even possible in a reasonable way, while being
>> stateless?
>>
>> Then, can someone explain to me how statelessness in a back-end
>> REST web service, promotes good code design, where user
>> interaction is a necessity? It seems to me that the client would
>> then need to maintain all the state, thereby tightly coupling all
>> the data points between the different controllers on the client.
>> Something like EJB allows you to pass around the stateful
>> pointer, and you simply add data as you go.
>>
>> After reading this stack exchange post, it's sounding like
>> everyone thinks that REST is NOT for users, but for services only.
>> http://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions
>>
>> I understand that it's more scalable, as the server always knows
>> exactly what you want, because you're telling it every time. But
>> it seems like that would come with a lot more boilerplate coding.
>>
>> Thanks.
>>
>
>