5 ms·

Why do API developers add a HTTP status code in their JSON response, when the HTTP status code is already in the header?

wmichelin 11y ago
Say you're making an ajax request to this API, you don't necessarily know the status, especially if you're in an "always" handler or something.
- taylorhughes 11y ago
  This but with jsonp might make sense; with xhr you can always get the http response code
woodruffw 11y ago
Probably because HTTP status codes are perceived to be at a different layer of the response than the body. A lot of developers (myself included, for trivial things) treat HTTP bodies as strings with no associated metadata.
- jsmthrowaway 11y ago
  It's debatable, but that's probably antithetical to how HTTP is supposed to be perceived when you start thinking about what a body is.
  - woodruffw 11y ago
    I would tend to agree. Speaking beyond convenience, this isn't a practice that's easy to justify ;)
X-Cubed 11y ago
Depending on the technology you're using to access the API, the HTTP status code may not be exposed from the underlying stack. For example, Microsoft Silverlight only returned 200 or 404 status codes: https://msdn.microsoft.com/en-us/library/system.net.httpstatuscode(v=vs.95).aspx#Anchor_1 https://msdn.microsoft.com/en-us/library/system.net.httpstat...
- jsmthrowaway 11y ago
  That would be called a "bug," and a perplexing one, at that.
greglindahl 11y ago
Because client coders don't always have access to the headers. Don't think of how you would write a client; think about how someone in the most messed-up programming environment that you can imagine is forced to write clients.
jonlucc 11y ago
I think it's to simplify as much as possible for clients. If a dev wants to use the API, it is in the interest of the API maintainer to make it easy, including pitting all the useful info in a single place. I was just watching an old talk about this a week ago from StormPath (iirc). They also recommend at least offering a trigger for including other redundant data like the path for subsequent sets of paginated data and an additional method for adding data via an URL flag instead of using PUT in case it isn't available.

wmichelin 11y ago

Say you're making an ajax request to this API, you don't necessarily know the status, especially if you're in an "always" handler or something.

taylorhughes 11y ago
This but with jsonp might make sense; with xhr you can always get the http response code

woodruffw 11y ago

Probably because HTTP status codes are perceived to be at a different layer of the response than the body. A lot of developers (myself included, for trivial things) treat HTTP bodies as strings with no associated metadata.

jsmthrowaway 11y ago
It's debatable, but that's probably antithetical to how HTTP is supposed to be perceived when you start thinking about what a body is.
- woodruffw 11y ago
  I would tend to agree. Speaking beyond convenience, this isn't a practice that's easy to justify ;)

X-Cubed 11y ago

Depending on the technology you're using to access the API, the HTTP status code may not be exposed from the underlying stack. For example, Microsoft Silverlight only returned 200 or 404 status codes: https://msdn.microsoft.com/en-us/library/system.net.httpstatuscode(v=vs.95).aspx#Anchor_1 https://msdn.microsoft.com/en-us/library/system.net.httpstat...

jsmthrowaway 11y ago
That would be called a "bug," and a perplexing one, at that.

greglindahl 11y ago

Because client coders don't always have access to the headers. Don't think of how you would write a client; think about how someone in the most messed-up programming environment that you can imagine is forced to write clients.

jonlucc 11y ago

I think it's to simplify as much as possible for clients. If a dev wants to use the API, it is in the interest of the API maintainer to make it easy, including pitting all the useful info in a single place. I was just watching an old talk about this a week ago from StormPath (iirc). They also recommend at least offering a trigger for including other redundant data like the path for subsequent sets of paginated data and an additional method for adding data via an URL flag instead of using PUT in case it isn't available.