https://kotlinlang.org logo
#android-architecture
Title
# android-architecture
u

ursus

03/16/2021, 12:37 AM
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
s

streetsofboston

03/16/2021, 1:50 AM
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.
u

ursus

03/16/2021, 2:35 AM
okay so you essentially have both, right? (400 + body where some json field says INVALID_PROMO_CODE)
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
s

streetsofboston

03/16/2021, 3:16 AM
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.
g

gildor

03/17/2021, 8:22 AM
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
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
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
s

streetsofboston

03/17/2021, 10:49 AM
@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.
u

ursus

03/17/2021, 1:27 PM
@gildor so whats your suggestion? Just have a single non 200 error code and then exact error enum in body?
g

gildor

03/17/2021, 1:28 PM
Well, I don't have suggestions, we all cursed by REST
In my perfect world I wouldn't never use rest for internal API
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
@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
u

ursus

03/17/2021, 1:51 PM
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?
g

gildor

03/17/2021, 2:35 PM
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
For auth error you just return unique auth error code and in data any additional data
u

ursus

03/17/2021, 2:45 PM
okay so whats your gripe with error codes? that theyre ambigous without docs? (but they do same body deserializing though)
g

gildor

03/17/2021, 2:49 PM
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
👍 1
12 Views