I have a REST API that for some of entpoinds like DELETE, POST or PUT I have some validation rules that can return an error.

Now I need a new type of an error like a non-critical error, that it should fail in a normal way, but should go for the action if there is a "supress warnings" flags send. Such an user can be asked: "Are you sure want to change this status, you are not finished yet"

Question: is there a best practice for these type of errors?

Secondary questions:

  • Are there any HTTP semantic for such behaviour that I can user?
  • do I still follow REST idea (for me it looks I do) - I keep it stateless
  • How do you decide whether to show such a warning to a user? You call an API endpoint to check the application status and then present the user such a dialog, blocking the UI until the user responds. Then you make the actual call. You should model this with you REST API too: add an endpoint to check whether it's save to do certain tasks. This way any API user is able to make "pre-flight" checks and even delegate decision to a user. Your HTTP status code approach is like a rm /file that "warns" the file is readonly while deleting it anyway. – try-catch-finally Apr 13 '16 at 21:55
  • This happens when business is overlapped with protocol status code. Anyways. Did you try to use your own 'HTTP status code? If Twitter can, you too. Lets say for example 6xx? Anyways so far I know, you can add messages into the response body even if it's 4xx (which range would be apropiated in your case). – Laiv May 13 '16 at 18:49
  • Finally I used 409 CONFLICT for warning response. This way, the client is instructed that it can force the call with the same endpoint and body with an exttra parameters "force=1" – user237329 Jan 27 '17 at 14:52

There are no warning result codes in http, you either return a success (200) or an error (400, 500). The only thing I know of that could be analogous to what you want is something like code 401 'unauthorised' - which is an outright failure, but causes most clients to automatically re-attempt connection with credentials.

For a REST API you need to tell the server the status of the request and how to handle the result - you cannot send a PUT and expect an error if the client is not finished, or success if it has - the server needs to know this information in order to send back the right result code.

So you can send the 'suppress warnings' flag with your request, if it is not set the server would return a 409 error code (or similar), and if set, return a 200 code instead. The user cannot be asked 'do you want to change this status' after the status change is sent.

You could make a request to the server to ask if the user can change status of course and follow with an appropriate request after that.

  • I'm in no way saying it's the right thing to do, but 3xx codes could be seen as some sort of notice or warning code where the client may decide to proceed. That said, I'd rather either perform an action or I don't, and maybe I return a response with additional information in the returned body or in headers. – Archimedix Apr 13 '16 at 20:50

If you wish to permit the user to override your normal error handling, you can consider returning a 200 SUCCESS status with additional information in extended HTTP headers. For example, you could return

X-APP-STATUS: 422 Unprocessable entity
X-APP-SOURCE: Invalid ID 'fo0'

This would give your client-side code the information necessary to either warn the user or take corrective actions on its own.

  • 2
    I never liked responses that say "I successfully failed" :-) – gbjbaanb Apr 14 '16 at 7:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.