You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 3, 2022. It is now read-only.
In the error handler?
Is it really though? It aint much work to return a number and it is a nice way of reading status quickly, rather than open up network tab and check which status was sent imo.
I would second this. HTTP protocol clearly has semantics for returning HTTP Error code and it is not in the payload. If I understand correctly this standard is trying to capture the common best practices of "pragmatic REST". It is not common or a best practice to have HTTP response code in the payload (e.g. JSON). Payload of an error condition should provide additional information.
As for the browser argument, Max provided – I think it would make sense if APIs were for humans (they are not) and also: in my experience most people who work with APIs either:
realize that browsers cannot do many other things besides easily showing headers (e.g.: make PUT and DELETE requests) and opt to use a more appropriate tool, such as Postman
employee more user-friendly interfaces to explore APIs, such as: Swagger.
@maxtotterman ,from client side, like ajax ,they have method to get http code, example: 5xx error, Server side error,retry request or implement a logic to deal with server side error,4xx error,mostly is client side input error, like params validate failed.2xx means request success. Restful api is use http status code to deal with program logics, no need to add an extra http code in response body.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
this is really useless
The text was updated successfully, but these errors were encountered: