4 ms·
Either way, if you're serving up a REST API to a JavaScript UI... what's NOT a good option is server-side session state (e.g. Java servlet sessions) Can you ex
by lr4444lr 10y ago
Either way, if you're serving up a REST API to a JavaScript UI... what's NOT a good option is server-side session state (e.g. Java servlet sessions)
Can you explain what you mean, as oppose to other kinds of session tokens?
Roy Fielding makes it abundantly clear[0] in the seminal delineation of REST that
We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
This has given me pause to doubt just how many people are really implementing REST, and/or how useful a model it is in modern web applications.
[0]https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
- meric 10y agoIMO sessions for authentication is fine as long as we don't store any session variables. In the end someone's going to be keeping track of the number of GET requests made by each API consumer on each endpoint, and practically it's not breaking REST as long as that state doesn't affect the information GETable by the client.
- lr4444lr 10y agoI just can't reconcile the fact that if I hit an endpoint, and I get back certain data with a 2XX response code because I previously accessed a "login" resource, but I would have gotten a 4XX response code if I had not gone to that prior "login" resource that I haven't violated REST: my request for the second endpoint takes advantage of stored context on the server. Even worse, if I restart the server, change out its database, or make some other stateful change on it, the response changes. And I don't mean to imply that this is a universal sin of computing architecture, but it sure as hell looks like a violation of REST, and it begs the question of what our standard is. Headers, path-based nomenclature, network layering, authentication - I'm on board with all of that. I just worry that a lot of people might be falling victim to commonplace misconceptions of just what REST is, which in turn may be causing us (the web dev community) to make misplaced value judgments.
- jayd16 10y agoRest doesn't mean no state in the world exists. It's not a violation at all that an endpoint changes its output. Rest only reasons about idempotency, not reproducibility.
- jdmichal 10y ago> Rest only reasons about idempotency, not reproducibility. Absolutely. If you GET a collection resource, then POST a new item into the collection, then GET the collection again, the response will have changed. Having these kind of temporal dependencies on the answer you receive is not something REST argues against.
- dragonwriter 10y agoNone of that violates REST; REST is not statelessness. In fact, REST (REpresentational State Transfer) is all about state and how it is changed and how those changes are manifested.
- Chris2048 10y agoSo, does this include web tokens too, or is auth a special case?
- throwaway2016a 10y ago> This has given me pause to doubt just how many people are really implementing REST, and/or how useful a model it is in modern web applications. Not many. I've made a good career out of consulting people who are doing REST wrong :) Usually they are either storing state or forgetting about HTAEOAS (Hypermedia). Often they are also negotiated format and version incorrectly and in a way that doesn't scale.
- woah 10y agoI'm going to contend that a "correct" implementation of REST has never existed