liberator
liberator copied to clipboard
clojure-liberator
202 Accepted only reachable from DELETE requests?
I can't see anything in the spec that implies that 202 Accepted should only be used for DELETE requests. Also, many REST resources seem to indicate that 202 Accepted is the (or a) proper way to implement mutation requests asynchronously, where you would return in the body an indication of where the client should go to check on the status of their mutation request.
Web Machine appears to have made the same decision that liberator has in making 202 reachable only from DELETE requests. Is there a reason behind this? Is there a workaround? Or am I stuck 303ing to the status resource which complicates clients somewhat.
While we're on the topic, 303 is also only available from the POST tree. Seems like I should be able to access that from a PUT?
Hey Tim, sorry your question got lost on my endless TODO list. Yes, liberator has basically the same transitions like webmachine -- it actually started as a literal port of it to clojure :-)
While the status codes available for the individual methods in liberator makes sense in general, I see that people like to have more control. I think a possible improvement is to add another decision after "respond-with-entity" to tell whether to respond with "204 no-entity" or "202-accepted". What do you think? The decision could be named "post-enacted?" and "put-enacted?" in line with "delete-enacted?"
+1 for this.
I have a use case where I want to respond with a 202 - accepted for POSTs whose content is recorded and processed at a later time.
I'm currently quite busy. PRs are always welcome, I will happily review them and always try to give constructive feedback! If anybody want's to tackle this and is unsure how, feel free to ask :-)
Where else do we want to have it reachable from? Sent from my BlackBerry 10 smartphone. From: Bobby CalderwoodSent: Saturday, October 3, 2015 6:13 PMTo: clojure-liberator/liberatorReply To: clojure-liberator/liberatorSubject: Re: [liberator] 202 Accepted only reachable from DELETE requests? (#210)+1 for this, I also have a use-case for POSTs handled asynchronously.
—Reply to this email directly or view it on GitHub.
@johnbendi A very common API pattern is to respond to all mutation requests with a 202 Accepted with a pointer to a status monitor. I was persuaded that it would also be appropriate to do a 303 See Other and use the Location header as that pointer. Even that in Liberator is hard, I believe, as DELETE and PUT requests can't naturally reach 303. So the point is that the two common async patterns (responding with 202 or 303 to PUT, POST, and DELETE) aren't internally supported by the decision graph.
I've been able to work around this issue (hopefully temporarily :-) via as-response:
...
:as-response (fn [d ctx]
(let [response (as-response d ctx)]
(if (::sync ctx)
response
(assoc response :status 202))))
...
@timvisher @bobby a PR would be appreciated :-∆ Especially some examples with 202 and status resource. I think that would be a good addition to liberator's examples.
@ordnungswidrig Any updates on this? Is this completed?
As suggested, we could have a post-enacted or put-enacted ... i was thinking if this should be right after post! and put! in the decision graph...
If this is ok with you, I can contribute with a code....
