3 ms·

But you're already doing this for actual non-error responses... I'm currently dealing with an endpoint where it sends anywhere from 2-4mb worth of JSON data. D

But you're already doing this for actual non-error responses... I'm currently dealing with an endpoint where it sends anywhere from 2-4mb worth of JSON data. Do I expect my clients to traverse every key and every deeply nested field to find what they're expecting for? Absolutely not. because there's an internally standardized way of dealing with things and that is also precisely how we also deal with errors. Now if you have an external API that faces many clients that you don't know about, then maybe there is consideration for usage of specific status codes. But even then, your api should have documentation for it.

sk5t 5y ago
Sorry, it seems like you're dug in on this, but you're forcing clients to deserialize enormous object graphs just to figure out if there was a failure or not. This is "surprising" behavior. A better designed system would use the HTTP status code, status reason, and perhaps an additional header to convey important high-level information.
- shroompasta 5y ago
  clients don't deserialize json. object graphs should be just called json or response body; you shouldn't use all these unorthodox terms. a failure will be caught if a 400 was sent. This is how axios works - if you try a request, a 400 will automatically hit the catch. a better designed system would be specificity. 75-90% of the time you're most likely going to look at the error body anyways.
  - sk5t 5y ago
    > clients don't deserialize json. I mean no personal offense but this is one of the most baffling and/or ignorant responses one could have imagined in this case.
    - shroompasta 5y ago
      a simple architecture json data => python server => redis - json data gets serialized from json to string in the python server - python server then stores that string in redis to request from python server - string is retrieved from redis server - string is deserialized to send response as json the Web client is in Javascript JSON is native to Javascript it is already readable to the client, there is no deserializing that needs to happen.

sk5t 5y ago

Sorry, it seems like you're dug in on this, but you're forcing clients to deserialize enormous object graphs just to figure out if there was a failure or not. This is "surprising" behavior. A better designed system would use the HTTP status code, status reason, and perhaps an additional header to convey important high-level information.

shroompasta 5y ago
clients don't deserialize json. object graphs should be just called json or response body; you shouldn't use all these unorthodox terms. a failure will be caught if a 400 was sent. This is how axios works - if you try a request, a 400 will automatically hit the catch. a better designed system would be specificity. 75-90% of the time you're most likely going to look at the error body anyways.
- sk5t 5y ago
  > clients don't deserialize json. I mean no personal offense but this is one of the most baffling and/or ignorant responses one could have imagined in this case.
  - shroompasta 5y ago
    a simple architecture json data => python server => redis - json data gets serialized from json to string in the python server - python server then stores that string in redis to request from python server - string is retrieved from redis server - string is deserialized to send response as json the Web client is in Javascript JSON is native to Javascript it is already readable to the client, there is no deserializing that needs to happen.