This content has moved permanently to:
https://blog.jonm.dev/posts/hypermedia-programming-lists/
Thursday, August 30, 2012
Subscribe to:
Post Comments (Atom)
skip to main |
skip to sidebar
The Art of Writing Software
Subscribe
Monthly Archive
All articles Copyright © 2007-2019 by Jon Moore. All rights reserved.
4 comments:
Would you want to be able to get either an index or a splice from your list? I would. How would that look? GET /favorites/10 ?
And if you do, then maybe you could also use that for insertion of new elements or a range of elements at a specific index. The typical stuff you can do in any regular list implementation.
@John: Those seem like natural things to want to do, for sure. However not all of those operations are natively supported by HTTP -- its current standard methods just don't have enough semantic expressiveness for this. I was pretty careful to stick *only* to things you could do with HTTP this way, as I think there aren't enough examples of what programming in this style really looks like.
Of course, you can always layer some of these extra list semantics on top with, say, HTML plus a semantic profile, where the operations were available via forms. I just currently have an interest in seeing what we can do with the standards we already have. I'd say list slicing isn't one of them off the top of my head.
In two places, you've specified PUT with a complete "new" version of the list. How, then, would we allow for concurrent-update (read-modify-write) races?
That is, if
- two clients GET the whole list, more or less concurrently
- each updates it in a different way
- both PUT their favorite new list
… then someone's changes are lost, aren't they? Did I miss something?
@Jack: typically you would handle this using optimistic concurrency and ETags. In your case, each of the two clients would do a GET and receive the same list with a given ETag. Each then attempts to do the PUT but making it a conditional PUT by specifying an If-Match header containing that ETag. If the server implements this atomically, then the first client in will succeed, and the second one will get a 412 (Precondition Failed) because the resource's current ETag doesn't match the one it supplied with If-Match. At that point it can re-GET to get the updated list and ETag, then proceed accordingly.
Post a Comment