4 ms·

> You're asking a remote system to do a job for you, and if that job completes successfully, it's a "Success" in the HTTP world. But a provided credit card num

> You're asking a remote system to do a job for you, and if that job completes successfully, it's a "Success" in the HTTP world. But a provided credit card number not existing is not success, it is unambiguously a failure. HTTP is a transport but its response codes are clearly designed to map somehow to the "business logic" of the thing underneath it. We have to twist ourselves up in knots to map most of our business systems to the set of status codes that make sense for the default HTTP-fronted application (Fields' thesis stuff) but that's what we sign up for when we decide to expose our business services via HTTP. Other transports require different contortions.

hugelgupf 7y ago
It is a failure, but not of the HTTP service. It's a failure of the RPC call. 404 means "this API doesn't exist", not "the API exists but it returns an error"
- sagichmal 7y ago
  404 does not mean "this API doesn't exist". It means, quote, The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. Resource here is a transport-level (HTTP) representation of a business-logic concept, in most cases a document, but if your HTTP server happens to front a credit card validation service, potentially a credit card. Or a user. Or a recipe.
stingraycharles 7y ago
Exactly. The parent is thinking along the lines of “but when the error is thrown successfully, it actually means success!” and at the same time missing out on an opportunity to leverage a well-understood error handling standard in HTTP.
- nulagrithom 7y ago
  Agreed. What else would you use 400 for? I don't see how sending back 400 is going to hurt. The payoff of using 400 is you can watch your 400 rates with almost no effort (HTTP is well established and there's many many tools out there.) If you somehow start accidentally munging the card number sometimes or if your card processor starts doing wacky stuff you'll see a spike in 400 rates. If it was really that troubling that declined cards are expected, I would personally at least want to see 200 come from the internal API and 400 go out to the client. And if your "intermediate devices" start doing goofy stuff to 400's then you've got bigger problems... 4xx's shouldn't be taking nodes out of prod. That's wack.
  - kyle-rb 7y ago
    >What else would you use 400 for? 400 is "bad request"; you might use it if the request body was not valid JSON.
  - stingraycharles 7y ago
    > 4xx's shouldn't be taking nodes out of prod. That's wack. Welcome to AWS, where this is actually part of standard procedure (at least Elastic Beanstalk does this, not sure if it’s actually Elastic Loadbalancer under the hood).
    - therein 7y ago
      Don't you love it when all configured backends/origins for a service are marked unhealthy through healthchecks, Amazon's load balancers route traffic to all origins.
      - Aeolun 7y ago
        I mean, the alternative is routing it nowhere. Might as well throw it at the wall and see if it sticks.
  - neop1x 7y ago
    In my opinion 404 should really mean the API endpoint doesn't exist and therefore the requested action did nothing. Using HTTP for business logic is like using ethernet frames with parts of IP. It is another level, HTTP is just a transport. 404 - not found, 5xx server problem, 301 - endpoint is now elsewhere etc. HTTP is for browser pages but you are actually making API requests using your JSON(or urlencoding or whatever)-based application protocol.
treis 7y ago
>But a provided credit card number not existing is not success, it is unambiguously a failure. But the failure is ambiguous. If I get a 404 back I can't rely on that to mean the credit card doesn't exist. It could mean that I have the wrong URL or that the service application screwed up their routing code.
- nulagrithom 7y ago
  You wouldn't put a card number in the path anyway (for obvious reasons). Far more sensible to put that in the request body. And who's to say you can't put the reason in the body and still keep the code? What are you hurting by sending back 400? Unless you have lb's taking out nodes because of excessive 4xx's (which sounds like insanity) I don't see a reason _not_ to send 4xx's. At the very least it's a useful heuristic tool.
  - treis 7y ago
    >And who's to say you can't put the reason in the body and still keep the code? Often systems will have application wide error handling to catch that and handle it in a systemic way. It can be a pain to short circuit that in a customizable off the shelf applications like Salesforce. Philosophically, 4XX means the client did something wrong. Sending invalid data to a validation service is not doing something wrong.
    - sagichmal 7y ago
      > Philosophically, 4XX means the client did something wrong. Sending invalid data to a validation service is not doing something wrong. The precise definition of 400 Bad Request is The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing). There's some room for interpretation for the phrase "process the request". If the only job of the service is to validate the request and return Valid or Invalid, then I guess yeah even an invalid request will have been processed, and 400 Bad Request may not be totally right. I think you could make a case for it! But I think you could also make a case for 200 OK with a more detailed error message and code in the body. But if the service both validates the request and _then_ does something more substantial with it, I think 400 Bad Request is probably the most appropriate response to something that fails at step one.
p1necone 7y ago
I typed up a big spiel about the difference between "expected in business logic failures" and "infrastructure failures", but then I looked at the wikipedia page for HTTP error codes and it does look like some HTTP 400 level errors are intended for cases like clients sending data that fails business logic level validation and the like.
- sagichmal 7y ago
  That's right. And let me say it's totally valid to just ignore that advice, and say that here, in this company, we use 200 OK for everything that isn't a parse failure. And that's not totally wrong! It won't break anything. You're not really leveraging any of the power of your transport but maybe that's fine for your situation.

hugelgupf 7y ago

It is a failure, but not of the HTTP service. It's a failure of the RPC call. 404 means "this API doesn't exist", not "the API exists but it returns an error"

sagichmal 7y ago
404 does not mean "this API doesn't exist". It means, quote, The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. Resource here is a transport-level (HTTP) representation of a business-logic concept, in most cases a document, but if your HTTP server happens to front a credit card validation service, potentially a credit card. Or a user. Or a recipe.

stingraycharles 7y ago

Exactly. The parent is thinking along the lines of “but when the error is thrown successfully, it actually means success!” and at the same time missing out on an opportunity to leverage a well-understood error handling standard in HTTP.

nulagrithom 7y ago
Agreed. What else would you use 400 for? I don't see how sending back 400 is going to hurt. The payoff of using 400 is you can watch your 400 rates with almost no effort (HTTP is well established and there's many many tools out there.) If you somehow start accidentally munging the card number sometimes or if your card processor starts doing wacky stuff you'll see a spike in 400 rates. If it was really that troubling that declined cards are expected, I would personally at least want to see 200 come from the internal API and 400 go out to the client. And if your "intermediate devices" start doing goofy stuff to 400's then you've got bigger problems... 4xx's shouldn't be taking nodes out of prod. That's wack.
- kyle-rb 7y ago
  >What else would you use 400 for? 400 is "bad request"; you might use it if the request body was not valid JSON.
- stingraycharles 7y ago
  > 4xx's shouldn't be taking nodes out of prod. That's wack. Welcome to AWS, where this is actually part of standard procedure (at least Elastic Beanstalk does this, not sure if it’s actually Elastic Loadbalancer under the hood).
  - therein 7y ago
    Don't you love it when all configured backends/origins for a service are marked unhealthy through healthchecks, Amazon's load balancers route traffic to all origins.
    - Aeolun 7y ago
      I mean, the alternative is routing it nowhere. Might as well throw it at the wall and see if it sticks.
- neop1x 7y ago
  In my opinion 404 should really mean the API endpoint doesn't exist and therefore the requested action did nothing. Using HTTP for business logic is like using ethernet frames with parts of IP. It is another level, HTTP is just a transport. 404 - not found, 5xx server problem, 301 - endpoint is now elsewhere etc. HTTP is for browser pages but you are actually making API requests using your JSON(or urlencoding or whatever)-based application protocol.

treis 7y ago

>But a provided credit card number not existing is not success, it is unambiguously a failure. But the failure is ambiguous. If I get a 404 back I can't rely on that to mean the credit card doesn't exist. It could mean that I have the wrong URL or that the service application screwed up their routing code.

nulagrithom 7y ago
You wouldn't put a card number in the path anyway (for obvious reasons). Far more sensible to put that in the request body. And who's to say you can't put the reason in the body and still keep the code? What are you hurting by sending back 400? Unless you have lb's taking out nodes because of excessive 4xx's (which sounds like insanity) I don't see a reason _not_ to send 4xx's. At the very least it's a useful heuristic tool.
- treis 7y ago
  >And who's to say you can't put the reason in the body and still keep the code? Often systems will have application wide error handling to catch that and handle it in a systemic way. It can be a pain to short circuit that in a customizable off the shelf applications like Salesforce. Philosophically, 4XX means the client did something wrong. Sending invalid data to a validation service is not doing something wrong.
  - sagichmal 7y ago
    > Philosophically, 4XX means the client did something wrong. Sending invalid data to a validation service is not doing something wrong. The precise definition of 400 Bad Request is The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing). There's some room for interpretation for the phrase "process the request". If the only job of the service is to validate the request and return Valid or Invalid, then I guess yeah even an invalid request will have been processed, and 400 Bad Request may not be totally right. I think you could make a case for it! But I think you could also make a case for 200 OK with a more detailed error message and code in the body. But if the service both validates the request and _then_ does something more substantial with it, I think 400 Bad Request is probably the most appropriate response to something that fails at step one.

p1necone 7y ago

I typed up a big spiel about the difference between "expected in business logic failures" and "infrastructure failures", but then I looked at the wikipedia page for HTTP error codes and it does look like some HTTP 400 level errors are intended for cases like clients sending data that fails business logic level validation and the like.

sagichmal 7y ago
That's right. And let me say it's totally valid to just ignore that advice, and say that here, in this company, we use 200 OK for everything that isn't a parse failure. And that's not totally wrong! It won't break anything. You're not really leveraging any of the power of your transport but maybe that's fine for your situation.