CODEWITHSUNDEEP
resthttp
Hobbyist
Hobbyist

Reputation: 16182

HTTP Status Code for Client being out of date

I'm working on moving my REST API away from always responding with a STATUS: 200 OK containing an error key in the JSON returned if there was a problem, and trying to use the correct status codes in the event of problems.

So far I've moved most parts of my server over to the proper status codes 200, 201, 400, 401, 403, 404, 500, 501, and 503

Currently I'm trying to figure out what the best way of rejecting the access to a API call for a client that is out of date. Currently I'm sending the version of the client encoded with the Authorization token.

I'm stuck between using status code 426, and 412. The title of the 426 status code seems like the use case I would want, but the description has me a little concerned. 412 looks like it would be appropriate if i moved my versioning away from the authorization token and put it inside of it's own header.

This is my first REST API, and it works great, I'm just trying to convert it to following best practices. So I'm a little boggled.

TLDR;

NOTE: My client is not a web browser. It is a mobile device.

Upvotes: 15

Views: 10726

Answers (3)

DaSourcerer
DaSourcerer

Reputation: 6606

Let us walk through your proposed solutions real quick: Status code 412 is now under authority of RFC 7232, section 4.2. It is to be used in the context of conditional requests if one or more preconditions described in section 3 of said RFC prevent the given request from being completed.

Code 426 is subject to RFC 7231, section 6.5.15. This code lets the client know that the [http] protocol version used to access a resource is too old to complete the request. Both of these codes do not apply here.

With a bit of help from this chart, I think two codes were adequate here:

400 is a bit vague (and deliberately so), indicating a general issue with the request.

This is a bit of a stretch as this code is indicating an authorization issue. However, it is not inherently linked to authentication, so you should be fine here.

Personally, I would go with 400. You may also want to take a look at RFC 7807 for a standardized way of transmitting API errors.

Upvotes: 14

Julian Reschke
Julian Reschke

Reputation: 42017

It would be a 4xx status code, but I don't think there is one specific to your use case. Thus, 400 should do. (You can send error details in the body, see, for instance, https://greenbytes.de/tech/webdav/rfc7807.html)

Upvotes: 1

Marco smdm
Marco smdm

Reputation: 1045

Hei Hobbyist...If you want to stick to official RFC release, then you should check the IETF site (Internet Engineering Task Force):

https://tools.ietf.org/html/

Not sure about which document, but for instance the HTTP/1.1 is part of RFC2616, but as I found in 2014 it was replaced by multiple RFCs (7230-7237).

The status 426 mentioned showed:

" A server that sends a 426 (Upgrade Required) response MUST send an Upgrade header field to indicate the acceptable protocols, in order of descending preference.

A server MAY send an Upgrade header field in any other response to advertise that it implements support for upgrading to the listed protocols, in order of descending preference, when appropriate for a future request.

https://www.rfc-editor.org/rfc/rfc7230#section-6.7 --> around page 57 you can find whole description :-) "

Please have a look at those documents in order to decide which error code to give it back :-)

I hope this clarify your query. I wish you a nice day!

Upvotes: 1

Related Questions