3 ms·

This article is missing one detail: what if resource creation fails? How do you signal that failure when the client calls GET on the task queue resource, in a w

by sltkr 8y ago

This article is missing one detail: what if resource creation fails? How do you signal that failure when the client calls GET on the task queue resource, in a way that's distinguishable from a failure to retrieve the task queue status?

Lazare 8y ago
You can't map everything cleanly to HTTP status codes. When you implement the task queue resource, you'll need to come up with ways of representing what information is important to you (status, success, failure, eta, progress, etc.), and then when you implement the client you'll have to parse that.
icebraining 8y ago
That's like asking whether you should send a 404 when you serve an article about a city that no longer exists. HTTP status codes refer to the resource being requested (in this case, the creation task itself), not to something that resource refers.
time0ut 8y ago
I think it depends a lot on why the operation failed and what you need the client to do next. If it is something the client can fix, I think it is reasonable to respond with the appropriate 4xx series status and enough to detail that they can correct and proceed. Same with 5xx series and issues that are out of the client's control. There are other approaches that are more or less as valid. The important thing is that we return enough information for the client to proceed. Wether that is signalled through status codes, headers, or response body isn't as important in my opinion.
geezerjay 8y ago
> This article is missing one detail: what if resource creation fails? I didn't get your point. If the resource creation fails during the request then either a 4 or 5 status is returned. If the resource creation succeeds but the long-running process fails in some way, either during processing or at creation time, then the resource representing the long-running process will be updated by the server to inform the client of the process' current status.

by sltkr 8y ago

Lazare 8y ago

You can't map everything cleanly to HTTP status codes. When you implement the task queue resource, you'll need to come up with ways of representing what information is important to you (status, success, failure, eta, progress, etc.), and then when you implement the client you'll have to parse that.

icebraining 8y ago

That's like asking whether you should send a 404 when you serve an article about a city that no longer exists. HTTP status codes refer to the resource being requested (in this case, the creation task itself), not to something that resource refers.

time0ut 8y ago

I think it depends a lot on why the operation failed and what you need the client to do next. If it is something the client can fix, I think it is reasonable to respond with the appropriate 4xx series status and enough to detail that they can correct and proceed. Same with 5xx series and issues that are out of the client's control. There are other approaches that are more or less as valid. The important thing is that we return enough information for the client to proceed. Wether that is signalled through status codes, headers, or response body isn't as important in my opinion.

geezerjay 8y ago

> This article is missing one detail: what if resource creation fails? I didn't get your point. If the resource creation fails during the request then either a 4 or 5 status is returned. If the resource creation succeeds but the long-running process fails in some way, either during processing or at creation time, then the resource representing the long-running process will be updated by the server to inform the client of the process' current status.