tps12

Recent Blog Comments By tps12

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Apr 4, 2013 at 9:21 PM

  @wizzszz, Right, you don't repeat "Bad Request," you spell out the reason it was rejected. E.g., "the specified 'foo' must be between 7 and 12." IMHO 5xx errors are the exclusive domain of the web server, and 4xx are fine to return from the application. Interestingly, just not... read more »

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Apr 4, 2013 at 7:18 PM

  @wizzszz, According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10 .4 all 4xx responses should describe the error in the response body.... read more »

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Apr 4, 2013 at 5:56 PM

  @wizzszz, "If your REST implementation resorts to a wild mixture of http and WebDAV it is nonetheless a "homegrown" protocol and does not follow standards..." Totally agree, that's my original reason for not liking 422 in this case. Our only difference is between "return ... read more »

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Apr 4, 2013 at 1:26 PM

  @wizzszz, It's not just AngularJS: Backbone, Spine, and presumably pretty much every other frontend framework that's around these days is geared towards talking to REST interfaces using the full assortment of methods and status codes defined in the HTTP spec. That's one reason it took me a minute ... read more »

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Mar 27, 2013 at 2:24 PM

  @wizzszz, Cool, I think we are just coming at things from totally different perspectives. If your API is limited to GETs and form data, then I can see that you wouldn't be able to rely on status codes as much as is possible in a more RESTful design. FWIW, PUT is very much part of HTTP/1.1 and in n... read more »

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Mar 27, 2013 at 11:51 AM

  @wizzszz, "Why would i respond to a PUT operation with a 200 when an error occurs?" So what do you use then? A client tries to PUT a resource and you determine that for whatever reason it's invalid in the context of your application and reject the request. The status code you use is...?... read more »

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Mar 27, 2013 at 7:46 AM

  @wizzszz, Fair enough. By the same token, if I were to attempt to update a resource with a PUT request when calling *your* API, and got a 200 status in response, then the last thing I would expect is that the resource might not in fact have been updated. Always interesting to hear other perspectiv... read more »

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Mar 26, 2013 at 6:06 PM

  @wizzszz, How is DELETE beyond the scope of HTTP? It's in the spec!... read more »

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Mar 26, 2013 at 6:20 AM

  @wizzszz, I guess I would quibble with "http status codes...have no relation to what happens in the business-logic layer." E.g., imagine an application where a given resource can only be DELETEd by certain users (admins, the resource owner, or whatever) as identified in the Authorization... read more »

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Mar 11, 2013 at 9:53 PM

  @wizzszz, I don't read the spec that way: if an XML request entity is not well-formed then respond 400 and say "couldn't parse XML" in the response body, and if it has a "foo" element in place of a "bar" then respond 400 and say "found foo in place of bar" in... read more »

• HTTP Status Codes For Invalid Data: 400 vs. 422

  Posted on Mar 10, 2013 at 10:46 PM

  Nah, 400 is correct in this case. "Syntax" doesn't just mean "well-formed XML" (or JSON or post data or whatever), it means that it's syntactically correct in the context of the application.... read more »