Given these example REST API / HATEOAS applications:
... where POST/PUT/PATCHING resources clearly alters the state/availability of (other) resources — for example in:
(REST example API 1)
PUT /order/1234 HTTP/1.1 ... <order> ... <status>preparing</status> ... </order>
... alters the state of the order, such that certain order options are not available anymore;
(REST example API 2)
PUT /games/1/doors/3 HTTP/1.1 ... {"status": "OPEN"}
... alters the state of the game, such that certain game options are not available anymore
— what would be wrong with treating a client session as a resource/an application state as well?
Consider this example, to see what I mean:
Let's imagine API key
1234
is the owner of/products/1
and only this API key is allowed to operate on/view this product.
Request:
GET /products/1 HTTP/1.1
Response:
HTTP/1.1 403 Forbidden
Request:
POST /sessions HTTP/1.1
Authorization: NiceAPI apikey=1234
<session>
<apiKey>1234</apiKey>
</session>
Response:
HTTP/1.1 201 Created
Location: /sessions/2ef4c...
// created session sent along for convenience
<session>
<hash>2ef4c...</hash>
<apiKey>1234</apiKey>
</session>
In response to Richard Tingle's comment, the above response could be adjusted to send a cookie, in stead of the hash in the session resource representation:
HTTP/1.1 201 Created
Set-Cookie: session=2ef4c...; Secure; HttpOnly
Location: /sessions/2ef4c...
<session>
<hash>2ef4c...</hash> // not necessary/desirable anymore
<apiKey>1234</apiKey>
</session>
... to bind the session resource to a client
Request:
GET /products/1 HTTP/1.1
X-Session: 2ef4c... // or a Cookie header, etc.
Response: (if server verified session resource exists)
HTTP/1.1 200 OK
// product content
Request:
DELETE /sessions/2ef4c... HTTP/1.1
Authorization: NiceAPI apikey=1234
Response: (if server verified session belonged to the API key)
HTTP/1.1 204 No Content
// session resource successfully deleted
Request:
GET /products/1 HTTP/1.1
Response:
HTTP/1.1 403 Forbidden
I mean, in both earlier mentioned REST API / HATEOAS applications the operations valid for any particular resource was dependent on other resource states and/or earlier client actions, as well (e.g. it's part of the application logic).
Given that client state/session management is generally frowned upon when talking about REST, how are the earlier mentioned REST API / HATEOAS application states different than my proposed session as a resource/application state?
Set-Cookie: session=2ef4c...; Secure; HttpOnly
header along with the201 Created
in stead of sending along<hash>2ef4c...</hash>
in the session resource. Would that be acceptable?