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