3 ms·

I like to find a middle ground. I use http status codes to encode how the _request_ was handled, not necessarily the data within the request. A 400 if you sen

I like to find a middle ground. I use http status codes to encode how the _request_ was handled, not necessarily the data within the request. A 400 if you send mangled JSON, but a 200 if the request was valid but does not pass business validation rules. Inside the 200 response is structured JSON that also has a status that is relevant at the application level. Otherwise how can for example you tell if a 404 response is because the endpoint doesn't exist, or because the item requested at the endpoint doesn't exist? I believe it's important to have a separation between what is happening at the API level vs Application, and this approach caters for both.

bvrmn 2y ago
> A 400 if you send mangled JSON, but a 200 if the request was valid but does not pass business validation rules. What about empty required field in JSON? Is it still mangled or it's already BL?
- LouisSayers 2y ago
  As it's not to do with the http request and the body was able to be parsed, in my book that'd be classified as being at the application level, so results in a 200 status with a JSON response detailing the issue 200 OK {status: "failed", errors: ["field X is required"]} How you deal with this on the application side, what JSON statuses you have etc is up to you.
  - bvrmn 2y ago
    It's an client error and it's highly beneficial to make it 400 for monitoring purposes. You want to see your FE or mobile devs deployed a faulty app.
    - LouisSayers 2y ago
      That depends on how you set up and do your monitoring. Not every failure needs to be indicated by an HTTP status code. For example, on a server I'm working on there are helper functions that generate different types of responses. Responding in certain ways will produce a 200, but will also log a warning or error. On the client side, you can create request helpers that all requests go through and that can resolve requests appropriately, rendering error messages to the user etc. The main thing is to have a well defined, consistent approach.
      - bvrmn 2y ago
        It's easier to do nothing (already available status codes) then to do something, isn't it? Developers are awful at following consistent approach.

bvrmn 2y ago

> A 400 if you send mangled JSON, but a 200 if the request was valid but does not pass business validation rules. What about empty required field in JSON? Is it still mangled or it's already BL?

LouisSayers 2y ago
As it's not to do with the http request and the body was able to be parsed, in my book that'd be classified as being at the application level, so results in a 200 status with a JSON response detailing the issue 200 OK {status: "failed", errors: ["field X is required"]} How you deal with this on the application side, what JSON statuses you have etc is up to you.
- bvrmn 2y ago
  It's an client error and it's highly beneficial to make it 400 for monitoring purposes. You want to see your FE or mobile devs deployed a faulty app.
  - LouisSayers 2y ago
    That depends on how you set up and do your monitoring. Not every failure needs to be indicated by an HTTP status code. For example, on a server I'm working on there are helper functions that generate different types of responses. Responding in certain ways will produce a 200, but will also log a warning or error. On the client side, you can create request helpers that all requests go through and that can resolve requests appropriately, rendering error messages to the user etc. The main thing is to have a well defined, consistent approach.
    - bvrmn 2y ago
      It's easier to do nothing (already available status codes) then to do something, isn't it? Developers are awful at following consistent approach.