3 ms·

For me, tradeoffs. Methods can be expressed in http method, and resource can be expressed in url. Response status can be expressed in http statuses. Some peop

For me, tradeoffs. Methods can be expressed in http method, and resource can be expressed in url. Response status can be expressed in http statuses. Some people prefer that for lower payload size. Others prefer byte encoded payloads like msgpack instead of json. In trading platform api's i've noticed that. Also, using url based resources lets you route these requests at the network proxy level (caddy haproxy nginx envoy traefik etc).

hinkley 4y ago
> Response status can be expressed in http statuses. This also simplifies circuit breaker work. The more error states you can interpret at the HTTP protocol layer the simpler it is to implement resiliency behavior. If you have to keep parsing responses looking for errors then you have to instrument every single call site separately - and distinctly. The more variation the harder it is to validate that they work properly.
- grogenaut 4y ago
  Funny enough I found that rolling most of the error types into one error type of circuit level that is either server failure or application logic failure is really where we wanted to go with circuit breakers. Having many new error types and not making the compiler and force you to check for those error types causes new errors to show up in an existing RPC method and no one notices it. Worse it either gets accidentally thrown into server errors which causes circuits to close when they shouldn't because it's actually a problem in the calling service, or they get thrown into user cases when they should actually be server failures and services continue to slam services that are actually broken. At work we mostly got it down to those two areas with lots of nuances under the business logic level issues as opposed to the server issues. However I don't think that using hundreds of status codes is the right way to go about it those two classes seem to be a really good place at the Hep binding and circuit breaker level. Circuit breakers in general are kind of tough.
  - hinkley 4y ago
    You can think of REST as having 600 status codes, or you can think of it as having about seven. - Enjoy - no it's over here - What are you talking about? - Who the hell are you? - Not for you - Nothing's here - I fucked up Only the last one should be associated with circuit breakers, which I think you already get. Then it's just two values to worry about. < 500, and >= 500
    - grogenaut 4y ago
      Oh I 100% agree with you.. though I think you're missing "you fucked up". My point is more just that people mess up and blur the lines accidentally either throwing exceptions which get propagated up as internal service errors when they should actually get run across the wire as business logic errors as part of you fucked up. Or really they didn't guard their code correctly and you get we fucked up when you really meant say overloaded. And it does start getting really blurry when you get into you fucked up. Or you are fucking up so hard that we fucked up and in fact our fucking up everybody else.
      - hinkley 4y ago
        400 You Fucked Up aka "What are you talking about?"
        grogenaut 4y ago
        aah missed it, I was cooking dinner. 100% agreed.
        hinkley 4y ago
        Originally I had them in random order and then I sorted them to try to make it easier for people to guess the status code from the colloquial description :)
        grogenaut 4y ago

hinkley 4y ago

> Response status can be expressed in http statuses. This also simplifies circuit breaker work. The more error states you can interpret at the HTTP protocol layer the simpler it is to implement resiliency behavior. If you have to keep parsing responses looking for errors then you have to instrument every single call site separately - and distinctly. The more variation the harder it is to validate that they work properly.

grogenaut 4y ago
Funny enough I found that rolling most of the error types into one error type of circuit level that is either server failure or application logic failure is really where we wanted to go with circuit breakers. Having many new error types and not making the compiler and force you to check for those error types causes new errors to show up in an existing RPC method and no one notices it. Worse it either gets accidentally thrown into server errors which causes circuits to close when they shouldn't because it's actually a problem in the calling service, or they get thrown into user cases when they should actually be server failures and services continue to slam services that are actually broken. At work we mostly got it down to those two areas with lots of nuances under the business logic level issues as opposed to the server issues. However I don't think that using hundreds of status codes is the right way to go about it those two classes seem to be a really good place at the Hep binding and circuit breaker level. Circuit breakers in general are kind of tough.
- hinkley 4y ago
  You can think of REST as having 600 status codes, or you can think of it as having about seven. - Enjoy - no it's over here - What are you talking about? - Who the hell are you? - Not for you - Nothing's here - I fucked up Only the last one should be associated with circuit breakers, which I think you already get. Then it's just two values to worry about. < 500, and >= 500
  - grogenaut 4y ago
    Oh I 100% agree with you.. though I think you're missing "you fucked up". My point is more just that people mess up and blur the lines accidentally either throwing exceptions which get propagated up as internal service errors when they should actually get run across the wire as business logic errors as part of you fucked up. Or really they didn't guard their code correctly and you get we fucked up when you really meant say overloaded. And it does start getting really blurry when you get into you fucked up. Or you are fucking up so hard that we fucked up and in fact our fucking up everybody else.
    - hinkley 4y ago
      400 You Fucked Up aka "What are you talking about?"
      - grogenaut 4y ago
        aah missed it, I was cooking dinner. 100% agreed.
        hinkley 4y ago
        Originally I had them in random order and then I sorted them to try to make it easier for people to guess the status code from the colloquial description :)
        grogenaut 4y ago