liberator
liberator copied to clipboard
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 303
ing to the status
resource which complicates clients somewhat.
ping :)
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.
+1 for this, I also have a use-case for POSTs handled asynchronously.
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....
https://github.com/clojure-liberator/liberator/pull/283