5 ms·

Ironically, your comment is a perfect illustration of one of the problems with REST - its tendency to provoke discussion about things that don't actually matter

Ironically, your comment is a perfect illustration of one of the problems with REST - its tendency to provoke discussion about things that don't actually matter in practice. No user cares whether an error response came back with a 400 or a 409 status, or what those codes even mean. It's madness that as a profession we spend so much of our employers' time and money on trivial things that deliver no value whatsoever. Response codes, HTTP verbs and pretty hierarchical URLs are all meaningless. I've lost count of the number of meetings I've been in where there have been pointless, timewasting debates about these things. Should we expose separate /foos and /bars endpoints? Should it be /foos/{foo_id}/bars/{bar_id}? Or maybe both? Do we need a POST, a PUT or a PATCH? Etc, ad nauseam. I'm generally cautious when it comes to embracing new technologies, but I've wholeheartedly embraced GraphQL simply because it has removed countless hours of unproductive bikeshedding from my professional life.

mariusor 6y ago
> No user cares whether an error response came back with a 400 or a 409 status Unless your product is itself an API, your users shouldn't be exposed to its status codes. Sorry for dispensing trite advice, but you should really have a nice client between API and users, that can translate the difference between 400 and 409 statuses in a comprehensible and friendly way. :)
- motogpjimbo 6y ago
  That's the purpose of an error message isn't it? I'm not sure what an HTTP response code is adding to that. In my experience, in any situation where you produce an API where you want the client to pay close attention to the actual error that occurred, the list of official HTTP response codes is generally woefully inadequate for the task and you're going to want to work with something much more specific. If my payment processor is telling me they're declining a transaction because the customer failed a fraud check, I'd rather they didn't communicate that to me with some random 4xx code one of their devs found on a Wikipedia article and tried to bend into shape. Rather, I'd hope the importance of the situation would lead them to compile a table of custom error codes that I can implement properly in my program's logic.
  - bickeringyokel 6y ago
    Let me get this straight, you don't think codes matter, but you want to manage a giant proptietary list of codes? Won't you just send up in those huge discussions you waste so much time on?
    - motogpjimbo 6y ago
      To continue the payment processor example, if there are 10 different reasons for declining a transaction, how do you propose mapping those onto 4xx codes? Would you just choose 10 at random? Or would you just return, e.g., E_INSUFFICIENT_FUNDS?
      - bickeringyokel 6y ago
        I'm not sure anyone would propose you randomly map different 4xx codes to a bunch of different internal server errors. For the one example you provided I would probably use a 500 code, return the relevant message and call it a day. In that case you might also return an additional code if you have some extremely complex logic for handling that error at the client side, but in that case your client might be a little too complicated. That doesn't mean I wouldn't also use the best practices codes for authentication vs authorization etc. I say this loosely though because best practices are really just that. It's more important to maintain a level of consistency within your team or organization so you're all speaking the same language. It's nice to have a starting point like rest APIs (or something that resembles them) so you're not writing a completely new rulebook on standard stuff that other people have already figured out, you can focus more on the problems your team is trying to solve. Why not use a 409 when there's a conflict? Someone already solved that problem. You can still return whatever pretty error message you want.
        hallman76 6y ago
        re: best practices. I inherited an API that always responds with 200s, even when there's an error condition. When a document can't be found it returns a 200 OK with a response body "NOT_FOUND". By ignoring existing standards and re-inventing the wheel with custom errors the previous development team made the system harder to maintain & harder to onboard.
jayd16 6y ago
REST doesn't have any monopoly on bikeshedding. That said, some of the practices (like being overly clever with status codes) are pointless while others are actually helpful design patterns. Using nouns over verbs helps you fully think through the process of mutating state in a RESTful/stateless way. The HTTP verbs all have a unique purpose you should understand. Does it always matter what size of hammer you use? No. That doesn't mean its smart to use a screwdriver as a chisel.
nuncanada 6y ago
I have been bitten by this really bad idea of reusing HTTP CODE for application problems. The server was 404 itself instead of the application. It is a bad engineering idea to reuse HTTP codes that can be thrown by multiple intermediaries confusing the client code.
- hnick 6y ago
  Where I work everything internal is a 503. Put a parameter out of range, or supply an ID not in the database? That's a server side exception. It's very frustrating even with a stack trace because I don't work on that code.
waspight 6y ago
But for graphql you will have the problem of naming the mutations instead. That is also a debate...
jjgreen 6y ago
It's all terribly simple: https://http.cat/ https://http.cat/
resonantjacket5 6y ago
interesting, I didn't know using graphQL could help remove so many design debates (compared to rest). But yeah it makes sense since with rest you have to keep thinking about whether or not you'll extend the /foos/{foo_id}/bars/{bar_id}/baz or say put it on its own resource /baz/{baz_id} etc... maybe I'll investigate graphql a bit more, I've just heard it was really complicated to implement the resolvers for the queries so people weren't using them yet.

mariusor 6y ago

> No user cares whether an error response came back with a 400 or a 409 status Unless your product is itself an API, your users shouldn't be exposed to its status codes. Sorry for dispensing trite advice, but you should really have a nice client between API and users, that can translate the difference between 400 and 409 statuses in a comprehensible and friendly way. :)

motogpjimbo 6y ago
That's the purpose of an error message isn't it? I'm not sure what an HTTP response code is adding to that. In my experience, in any situation where you produce an API where you want the client to pay close attention to the actual error that occurred, the list of official HTTP response codes is generally woefully inadequate for the task and you're going to want to work with something much more specific. If my payment processor is telling me they're declining a transaction because the customer failed a fraud check, I'd rather they didn't communicate that to me with some random 4xx code one of their devs found on a Wikipedia article and tried to bend into shape. Rather, I'd hope the importance of the situation would lead them to compile a table of custom error codes that I can implement properly in my program's logic.
- bickeringyokel 6y ago
  Let me get this straight, you don't think codes matter, but you want to manage a giant proptietary list of codes? Won't you just send up in those huge discussions you waste so much time on?
  - motogpjimbo 6y ago
    To continue the payment processor example, if there are 10 different reasons for declining a transaction, how do you propose mapping those onto 4xx codes? Would you just choose 10 at random? Or would you just return, e.g., E_INSUFFICIENT_FUNDS?
    - bickeringyokel 6y ago
      I'm not sure anyone would propose you randomly map different 4xx codes to a bunch of different internal server errors. For the one example you provided I would probably use a 500 code, return the relevant message and call it a day. In that case you might also return an additional code if you have some extremely complex logic for handling that error at the client side, but in that case your client might be a little too complicated. That doesn't mean I wouldn't also use the best practices codes for authentication vs authorization etc. I say this loosely though because best practices are really just that. It's more important to maintain a level of consistency within your team or organization so you're all speaking the same language. It's nice to have a starting point like rest APIs (or something that resembles them) so you're not writing a completely new rulebook on standard stuff that other people have already figured out, you can focus more on the problems your team is trying to solve. Why not use a 409 when there's a conflict? Someone already solved that problem. You can still return whatever pretty error message you want.
      - hallman76 6y ago
        re: best practices. I inherited an API that always responds with 200s, even when there's an error condition. When a document can't be found it returns a 200 OK with a response body "NOT_FOUND". By ignoring existing standards and re-inventing the wheel with custom errors the previous development team made the system harder to maintain & harder to onboard.

jayd16 6y ago

REST doesn't have any monopoly on bikeshedding. That said, some of the practices (like being overly clever with status codes) are pointless while others are actually helpful design patterns. Using nouns over verbs helps you fully think through the process of mutating state in a RESTful/stateless way. The HTTP verbs all have a unique purpose you should understand. Does it always matter what size of hammer you use? No. That doesn't mean its smart to use a screwdriver as a chisel.

nuncanada 6y ago

I have been bitten by this really bad idea of reusing HTTP CODE for application problems. The server was 404 itself instead of the application. It is a bad engineering idea to reuse HTTP codes that can be thrown by multiple intermediaries confusing the client code.

hnick 6y ago
Where I work everything internal is a 503. Put a parameter out of range, or supply an ID not in the database? That's a server side exception. It's very frustrating even with a stack trace because I don't work on that code.

waspight 6y ago

But for graphql you will have the problem of naming the mutations instead. That is also a debate...

jjgreen 6y ago

It's all terribly simple: https://http.cat/ https://http.cat/

resonantjacket5 6y ago

interesting, I didn't know using graphQL could help remove so many design debates (compared to rest). But yeah it makes sense since with rest you have to keep thinking about whether or not you'll extend the /foos/{foo_id}/bars/{bar_id}/baz or say put it on its own resource /baz/{baz_id} etc... maybe I'll investigate graphql a bit more, I've just heard it was really complicated to implement the resolvers for the queries so people weren't using them yet.