Timeline for What is wrong with treating a client session as a resource/application state in REST architecture?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot | Commonmark migration | |
| May 23, 2017 at 11:33 | history | edited | CommunityBot | replaced http://stackoverflow.com/ with https://stackoverflow.com/ | |
| Jun 7, 2016 at 18:13 | history | edited | VoiceOfUnreason | CC BY-SA 3.0 | added 315 characters in body |
| Jun 5, 2016 at 23:17 | history | edited | VoiceOfUnreason | CC BY-SA 3.0 | added 591 characters in body |
| Jun 5, 2016 at 16:09 | history | edited | VoiceOfUnreason | CC BY-SA 3.0 | added 293 characters in body |
| Jun 5, 2016 at 14:44 | history | edited | VoiceOfUnreason | CC BY-SA 3.0 | added 194 characters in body |
| Jun 4, 2016 at 11:50 | comment | added | Decent Dabbler | In example 2: The state of a door resource determines the state of the game resource. If a door is opened, the game resource state changes, plus you wouldn't be able to open another door resource anymore either. You'd probably get a IllegalTransitionException, resulting in a 409 Conflict status, or something similar. If REST / HATEOAS would only be about changing resource state (which HATEOAS certainly shouldn't, given the AS part of the acronym) then wouldn't they simply be glorified CRUD data warehouse architectures, without any business logic? | |
| Jun 4, 2016 at 11:49 | comment | added | Decent Dabbler | Concerning the application state of the examples: sorry, let me clarify. In example 1: if the barista is preparing the order, no additional items can be added to the order. Application logic is needed to evaluate the content of the resource to determine what further adjustments (if any) are allowed to be made to the order. But perhaps a more convincing example of application state here would be if the payment resource (/payment/order/1234) was created: the state of that resource also restricts any further actions allowed on the order resource. | |
| Jun 4, 2016 at 11:47 | comment | added | Decent Dabbler | Concerning the browser back button: couldn't I just issue a Vary: Cookie header to mitigate caching? And doesn't this back button caching issue also not hold for any other previous application state and its resource representations when the state of a resource has since evolved (as you described in your blog post)? If the barista (of example 1) is preparing our order, but we haven't refreshed /order/1234 yet while we went somewhere else in the meantime and then go back in history, our order representation isn't valid anymore either. In both cases you need caching mitigation mechanisms, no? | |
| Jun 4, 2016 at 5:22 | history | edited | VoiceOfUnreason | CC BY-SA 3.0 | added 94 characters in body |
| Jun 4, 2016 at 1:20 | history | answered | VoiceOfUnreason | CC BY-SA 3.0 |