Status code for full collection

[Aria]

What status code would you throw on a denied PUT or resource-creating POST request because the collection is full to some (business-logic derived) limit?

[mca]

If the problem is "fixable" by the client I usually return 400 w/ a body that explains the problem in greater detail. If the problem is server-related and not "fixable", then I return 500 w/ a body that explains the problem in greater detail.

If that doesn't fit your needs, you can dip into the WebDAV status codes for something more to your liking[1]. 

507 (Insufficient storage) might do the trick.

Cheers.

[1] http://www.webdav.org/specs/rfc2518.html#status.code.extensions.to.http11

mca

+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Fri, Mar 22, 2013 at 11:22 AM, Aria <ared...@nbtsc.org> wrote:

What status code would you throw on a denied PUT or resource-creating POST request because the collection is full to some (business-logic derived) limit?

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ted M. Young [@jitterted]]

> I usually return 400 w/ a body

Literally a '400' or a 4xx series? I was thinking a 409 Conflict might work here (with more info in the body) since the client _could_ resolve the conflict by deleting some items in the collection. I could also see 405 Method Not Allowed being used.

I thought that the 5xx series indicated that there was a problem with the server, but here "full" is defined as a business (domain) limit?

;ted

[mca]

Ted:

when i am mapping to HTTP my initial work is to map any client-side error to 400 and server-side error to 500. If, in the reviews/iterations another 4xx/5xx works out better, i use it. But the app-specific body is the key to all this. 

client app are always (in my impl.) given guidance to check the body for details.

 

mca

+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

[Mike Kelly]

Do you not negotiate auth via 401's and WWW-Authenticate?

Mike

http://twitter.com/mikekelly85
http://github.com/mikekelly
http://linkedin.com/in/mikekelly123

[mca]

yep

mca

+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

[Ted M. Young [@jitterted]]

Interesting. I'm still a novice at this stuff (we just had a discussion about 405 vs. 409 in our study group yesterday), but using the 400 error instead of something possibly more precise feels like tunneling errors through two status codes (which makes me cringe because I'm also dealing with the "private" error codes in JSON-RPC). I can understand starting with 400 if nothing immediately comes to mind, but aren't we told by the "experts" (aka those who write the books and give the talks) that we should use more than just a couple of status codes?

;ted

[mca]

if that response is address to me...

use whatever fits your needs. 

if you read my message and think i am telling you to ONLY use 400 and 500 for all cases, you missed my point.

if you think that you should NEVER use 400 since it's too generic, you missed my point.

if you, however, picked up that the most important part of the error response, REGARDLESS of the protocol-level response code you use, is the details in the body, you get my point.

does that help?

mca

+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

[Felipe Sere]

 I would also add another argument to that:

Adhering 100% to the status codes in the HTTP means that your client hast to be aware of the same granularity of status codes. 

Furthermore there are some status codes which by convention are used in certain common situations:

409 Conflict --> something was wrong with the ETag, check that

405 Method Not Allowed --> I used an invalid verb. 

I would be surprised if I got any of these two errors for anything other than the above. 

My advice: try to keep the amount necessary status codes to usable minimum and only dive into the depths of the spec if necessary. 

( e.g. We implemented a 412 if the client sent an If-Match: * header while creating a resource with PUT and our clients hated us, even though that is what the spec says....)

--

You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Gruß,
Felipe

[Peter Williams]

On Mar 22, 2013 10:35 AM, "Felipe Sere" <felip...@gmail.com> wrote:
>
>  I would also add another argument to
> that:
> Adhering 100% to the status codes in the
> HTTP means that your client hast to be
> aware of the same granularity of status
> codes. 

This is not true. Clients must be prepared to cope with any response code whether or not your api can generate it today. Per the HTTP spec [1]:

"applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class"

A client that blows up when it encounters an unrecognized response code is broken. Period. Clients don't have any control over what the server sends them so they should be resilient to small changes like the use of more or less specific response codes. Otoh, clients are always free to treat any status they don't specifically understand, or don't care about, as the x00 code for its class so this requirement is not all that much work.

[1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1

Peter
Barelyenough.org

[Felipe Sere]

Hmm... My simplest case is the introduction of ETags and 409/412 status codes. 

You MAY treat is a 4xx, but only if you know that a 412 means "do a GET again, read the current state of the sever, merge it with your current state and send it with the last ETag". If you just treat is as a 400 and resend your request little will happen. 

There is a difference between "not exploding" and "understand the meaning of a status code in the context of a request/API". 

--

You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Gruß,
Felipe

[Daniel Roop]

I tend to agree with @mca on this one.  We usually start by mapping to the right range of errors (as described above)and then look for a more specific one.

I also make heavy use of the body to provide more application specific error information.

I would also add that I tend to care about status codes from a protocol level not from an application level.  Put another way I believe any logic based on status code behavior should be able to be implemented into a generic library. Whereas anything meaningful to the application should be in the body.

Daniel

On Mar 26, 2013 11:19 AM, "Aria" <ared...@nbtsc.org> wrote:

Interesting. I'd not considered 409.

[Mike Kelly]

On Wed, Mar 27, 2013 at 1:02 PM, Daniel Roop <goof...@gmail.com> wrote:
> I would also add that I tend to care about status codes from a protocol
> level not from an application level. Put another way I believe any logic
> based on status code behavior should be able to be implemented into a
> generic library. Whereas anything meaningful to the application should be in
> the body.

Indeed. This is the fundamental purpose of a uniform interface - to
facilitate intermediate processing.

To put it another way: the easiest way to figure out if you're making
the "best" use of HTTP for a given interaction is to assume the
perspective of a proxy.

Cheers,
M

[Peter Williams]

On Wed, Mar 27, 2013 at 7:02 AM, Daniel Roop <goof...@gmail.com> wrote:
> I would also add that I tend to care about status codes from a protocol
> level not from an application level. Put another way I believe any logic
> based on status code behavior should be able to be implemented into a
> generic library.

How do you square this view with the fact that it is -- or at least
seems to me to be -- impossible to implement handling logic for almost
all the standard 4xx status codes generically? For example, how could
one implement 409 Conflict recovery generically in an HTTP library?
`Unauthorized`, `Proxy Authentication Required` and `Request Timeout`
are the only ones for which have obvious generic implementations. Even
handling that last one generically is a bit dodgy.

If one or more media types specifications are encompassed by the word
"protocol" then we might have something to hang our hat on but that
seems a bit of a stretch.

I tend to view status codes in the 4xx class as entirely application
level. They indicate various failure modes that are common to many
applications. HTTP is an application protocol so some of those
application error scenarios are going to be general enough that we can
have semi-generic handling for them. Others -- the majority, in fact
-- must be handled differently depending on the media type of the
application at hand. Or if we are really unlucky, handling will be
based on some out of band knowledge about what the server expects user
agents to do for that status code.

(I say semi-generic above because even the easy ones are not really
all that simple. For example, correctly handling `Unauthorized`
depends on understanding the auth-scheme of the `WWW-Authenticate`
header field.)

Peter
barelyenough.org