6 ms·
> Then if we try to submit the payload with the email value that already exists in users, we’ll get a 400 response status code with a 'User already exists' mess
by numlock86 6y ago
> Then if we try to submit the payload with the email value that already exists in users, we’ll get a 400 response status code with a 'User already exists' message to let users know that the user already exists. With that information, the user can correct the action by changing the email to something that doesn’t exist.
I was always under the impression that 409 would be the "correct" code here, while you'd use 400 if the API user didn't supply an email at all, for example.
- ed25519FUUU 6y agoIsn’t 409 if you’re trying to update an existing record (PUT) and not create a new record (POST)? The ambiguity is probably why most people just use 400 and call it a day.
- BerislavLopac 6y agoThere's this, FWIW: https://i.stack.imgur.com/whhD1.png https://i.stack.imgur.com/whhD1.png
- motogpjimbo 6y agoPlease tell me that's satire...
- motogpjimbo 6y agoIronically, 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 agoThat'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 agoLet 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 agoTo 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?
- 6y ago