News for hackers. Stuff that matters.

A comment on Designing a Pragmatic RESTful API. Parent comment

Re:Designing a Pragmatic RESTful API by kailuowang on Tuesday June 04, 2013 @12:13PM (#5820319)
If I understand your solution correctly, does it mean that it's now the client's obligation to get the content from the revert-to version and create a new version and POST it to /posts/X/versions? That should work, but what if I don't wanna give the client the ability to create version arbitrarily (only allowed to revert to a pre-existing version)?
[ Parent | on HN ]
Re:Designing a Pragmatic RESTful API by mtrimpe on Tuesday June 04, 2013 @12:26PM (#5820403)
My first solution was assuming you could not revert. If you want to allow revert then the client would first call /posts/X/versions, get a list of all versions and then either do

    PATCH /posts/X
    { "version": "older-revision" }
or

    PATCH /posts/X/versions/older-revision
    { "active": true }
Access control is completely orthogonal to this; so for your sample case you would just return a 403 for any other calls (like e.g. POSTs to /posts/X/versions)
[ Parent | on HN ]