I was doing some research on status codes yesterday after @bretterer brought up some great points yesterday about #69 and #71.
Status codes are really useful when you're building a generic client, or for discoverability when you're messing around with the API in something like Postman. However, as an API client consumer, there are at times so many status codes in the HTTP spec, I am not going to try catching them all. Instead, I rely on documented behavior for each endpoint and only look at those relevant status codes.
Facebook uses just several (200 OK, 30x redirects, and 400/500 errors), Twitter documents 15 status codes, and Dropbox uses 10 (but is planning on reducing the number).
I think it may be useful for people writing API clients to define all the "valid" status codes from our framework, and stick to a subset of the HTTP spec.
I was doing some research on status codes yesterday after @bretterer brought up some great points yesterday about #69 and #71.
Status codes are really useful when you're building a generic client, or for discoverability when you're messing around with the API in something like Postman. However, as an API client consumer, there are at times so many status codes in the HTTP spec, I am not going to try catching them all. Instead, I rely on documented behavior for each endpoint and only look at those relevant status codes.
I looked into what other API providers are doing, and found this great article from Dropbox.
Facebook uses just several (200 OK, 30x redirects, and 400/500 errors), Twitter documents 15 status codes, and Dropbox uses 10 (but is planning on reducing the number).
I think it may be useful for people writing API clients to define all the "valid" status codes from our framework, and stick to a subset of the HTTP spec.