Do you have opinions on rest api error design? Ex...

# android-architecture

[ursus]

Do you have opinions on rest api error design?

Example: Entering a incorrect (made up) promo code.

Is this a http code 400

or

200 + json body error=INVALID_PROMO_CODE

[streetsofboston]

I prefer proper http error code responses. Easy to check without the need to parse the body.

Eg a 200 body has one type of Json object response and a 500 body may have a another type of Json object response. With an http response code that differs, switching/selecting the proper Json deserialization is easy.

[ursus]

okay so you essentially have both, right? (400 + body where some json field says INVALID_PROMO_CODE)

[ursus]

my gripe with http codes is that who knows what they mean, 404 could mean the last resource is missing, or some parent as well, etc, ambigious .. here the constant could help yea

[streetsofboston]

Yup.
Eg a 200 response will have a body of any Json that is needed/required by the API call, while a 4xx and/or 5xx will have a fixed Json error message message (eg error-code and error-message) for its body.

[gildor]

If it “REST-full” it should return error code
But IMO it’s terrible API and any simple RPC based solution is much better solution

Really wish history of API would be different

[gildor]

Easy to check without the need to parse the body.

You still have to parse body, otherwise you will show wrong error message to user, if this 400 means something else

[gildor]

so if you say that it’s rest api, it should really return error code in this case

though, it doesn’t mean it’s good by itself, it’s hard to work with it, http error codes are always ambigious

[streetsofboston]

@gildor I should have said "Easy to check before the need to parse the body" 😃

The body of an error is often in a different format (either totally different format or Json of a different type of object) than a 200 response. With an error code it's easier to select a deserializer that is appropriate for the returned response.

[ursus]

@gildor so whats your suggestion? Just have a single non 200 error code and then exact error enum in body?

[gildor]

Well, I don't have suggestions, we all cursed by REST

[gildor]

In my perfect world I wouldn't never use rest for internal API

[gildor]

But for rest, yes, you should find an error code which kinda works for you case (400, 401, 403 or whatever, any who use it anyway will require to check docs) and include an actual error code and message to error body response

[gildor]

@streetsofboston well yes, but it solves problem created by this approach, when you have different error/success format. Also by using http statuses you forced to use different ones for different cases and rely on http protocol

[ursus]

what would you like in ideal world, grpc?

never used that before, how would they signal access tokens expired? just some error=auth_expired enum?

[gildor]

Any rpc, for a long time on my previous project we used solution similar to json-rpc, but just own internal, it's super simple protocol actually

Grpc has many other cool features though, but it's of course very opinionated solution, also requires additional friction for web

Though, I would love to use grpc, it's indeed very powerful

[gildor]

For auth error you just return unique auth error code and in data any additional data

[ursus]

okay so whats your gripe with error codes? that theyre ambigous without docs? (but they do same body deserializing though)

[gildor]

Every method has list of errors, not like 400 which just mean that client did something wrong on any level, it may be even not an error, but enum with result