Timeline for Roy Fielding’s REST alternative to HTTP cookies
Current License: CC BY-SA 4.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 28, 2021 at 12:44 | answer | added | JacquesB | timeline score: 1 | |
| May 28, 2021 at 2:09 | history | edited | Géry Ogam | CC BY-SA 4.0 | edited body |
| May 27, 2021 at 23:57 | vote | accept | Géry Ogam | ||
| May 27, 2021 at 15:30 | answer | added | Robert Bräutigam | timeline score: 1 | |
| May 27, 2021 at 14:01 | history | reopened | JacquesB Géry Ogam Doc Brown | ||
| May 26, 2021 at 10:53 | comment | added | JacquesB | To be clear, Fielding is not saying that you should stop using cookies for shopping-cart state. He is saying the people who designed and implemented the cookie protocol could have made better design decisions. But now cookies is what the have. The alternatives I suggested (SPAs, LocalStorage) did not even exist at the time he wrote. | |
| May 26, 2021 at 6:31 | comment | added | JacquesB | Fielding is talking about a general architectural style, not any particular implementation. He is not even talking specifically about HTML, but in general about "hypermedia data formats". The use of JavaScript was just my example of a possible implementation of a shopping basked satisfying REST. | |
| May 25, 2021 at 22:52 | comment | added | Géry Ogam | @JacquesB So in the browser, if we want our website to keep working when Javascript is disabled, we only have the solution storing the application state in the URI (since client-side storage is not supported natively in the browser through HTML elements but requires Javascript to call the History API explicitly). | |
| May 25, 2021 at 19:35 | comment | added | JacquesB | These are two different possible solutions. You wouldn't do both at the same time. | |
| May 25, 2021 at 19:24 | comment | added | Géry Ogam | Thanks @JacquesB. You said that application state is stored in the URI (like in the user preference example). Then what is the point of storing it locally on the client (like in the shopping cart example)? | |
| May 25, 2021 at 18:49 | comment | added | JacquesB | Yes, the first bullet point seem to reflect Fieldings view pretty closely. | |
| May 25, 2021 at 18:41 | comment | added | Géry Ogam | @JacquesB Yes it is. I also gave my interpretation in Example. Is it correct? | |
| May 25, 2021 at 18:38 | comment | added | JacquesB | Is the first bullet point a question or an answer to the question? | |
| May 25, 2021 at 17:41 | comment | added | JacquesB | I don't think he had anything as specific as a HTML element in mind for the shopping cart. His point is just that the state should be handled on the client side. It could be something built into the browser or it could be a SPA or it could be JavaScript + LocalStorage. As long as the session state exist purely on the client side. REST is not really about concrete formats like HTML or JavaScript, it is about general principles. | |
| May 25, 2021 at 17:16 | comment | added | Robert Harvey | Thanks for the updates to your question, but it doesn't really change what was said in the comments. Roy Fielding's REST was never meant to inform the kinds of decisions you're proposing in your question, and I agree that what the industry has come to describe as REST really has little to do with Roy Fielding's original thesis. | |
| May 25, 2021 at 15:44 | comment | added | Géry Ogam | @JacquesB I have updated my post with more precise questions. | |
| May 25, 2021 at 15:41 | comment | added | Géry Ogam | @FilipMilovanović Thanks, I think that I understand better what he meant about his shopping cart example. I have updated my post with more precise questions. | |
| May 25, 2021 at 15:31 | history | edited | Géry Ogam | CC BY-SA 4.0 | added 1977 characters in body |
| May 25, 2021 at 8:42 | comment | added | JacquesB | Perhaps you should indicate what parts you struggle to understand, since I just end up repeating what the quote says. | |
| May 25, 2021 at 8:35 | comment | added | JacquesB | HTTP was initially designed as a stateless protocol where any application state is represented in the URL, and the client change state by following URLs. Cookies muddied this by introducing a separate session state. For example pressing the back button should always bring you back to the previous state, but this is not necessarily the case with cookies. If I send a link to you, you might not actually see the same page or resource since you don't have the same cookie. | |
| May 25, 2021 at 8:18 | review | Reopen votes | |||
| May 27, 2021 at 14:07 | |||||
| May 25, 2021 at 6:43 | history | closed | Eric King gnat Jörg W Mittag | Needs more focus | |
| May 25, 2021 at 6:32 | comment | added | Filip Milovanović | He seems to be saying that these features should have been somehow made part of the protocols in a way that lets the browser / user agent understand what's going on (e.g. like it understands the semantics of HTML). Notice, for example, that one of his complaints is about cookies being opaque to the browser (because it can't understand proprietary, application-specific formats). This would require people to agree on a set of standards for these things, though. Besides, application vendors would still want the ability to operate outside of these constraints, to offer flashy features 3/3 | |
| May 25, 2021 at 6:31 | comment | added | Filip Milovanović | So, you see, there are somewhat conflicting interests, which, I'm guessing, lead to protocols being augmented with features (like cookies and frames) that were not quite in line with the original vision/architecture. I'm not 100% certain I'm correct, but I don't think he's necessarily proposing a better alternative (i.e., it's not meant to be practical now), I think he's describing what would have been more historically desirable, from the perspective of the protocol community. 2/3 | |
| May 25, 2021 at 6:31 | comment | added | Filip Milovanović | Just so that we're on the same page, be aware that Roy Fielding’s REST has almost nothing to do with what the software industry calls REST; he's not talking about a better way to make web services, he's describing the architecture of the Internet, in a generalized way. His viewpoint is that of a protocol developer. When he says 'application', he means one that operates within the rules and constraints of the architecture and the application-level protocols of the Web. Web developers don't necessarily want to be too constrained by that, opting to treat the Web more as a delivery mechanism. 1/3 | |
| May 25, 2021 at 1:48 | review | Close votes | |||
| May 25, 2021 at 6:51 | |||||
| May 24, 2021 at 23:35 | history | asked | Géry Ogam | CC BY-SA 4.0 |