Some of the checks I make to validate http requests involve making a call to an external service to parse part of the request body. These calls can fail because of network connectivity issues. My feeling is that I should return a 5xx error to indicate that the client may want to try again later.
However, what do I do if there's a network problem when performing one check, AND another check that doesn't need the network connectivity fails (e.g. the client sends in a string where a number is required)? Should I return a 4xx if I expect the network error to be transitory (giving the client a chance to fix the client error while the server fixes the server error), and a 5xx otherwise to tell the client not to bother trying with a different input immediately? Does it depend on the specific types of 4xx and 5xx I would have returned? Is there a standard solution?
I did come across What HTTP status code to return if multiple actions finish with different statuses? where one of the answers suggests using a 207 "Multi-Status" code but this seems strange (to me at least--aren't 2xx codes supposed to indicate some sort of success?).
I want to give a few more specifics about my particular case. I'm working on updating an existing REST service that creates a long-running (potentially days) batch process. Before a batch process is created, the service does validation of the POST request parameters.
Some of the parameters in the POST request are easy to validate (e.g. is a string non-empty, can the string be parsed as a date). One of the parameters, however, is supposed to be a string in DSL. I can validate this DSL string by sending it on to another REST service and seeing what I get back. I'm not exactly sure how reliable this validation service is, but I suspect that there's a reasonable chance that it could be down for a few hours at a time AND there's a reasonable chance that when it is down it is only down for a few seconds.
I'm expecting that crafting the DSL strings correctly is going to be significantly more difficult than changing a string to a number for end users. End users may not want to spend time working on fixing their DSL string if the service is likely down for the rest of the day.
All this said, I guess I really have a set of general questions:
- Even in situations like mine, are there any straightforward answers/rules of thumb like, maybe, "503 trumps 400", or "400 trumps 500", or "use this obscure code"?
- Are there other possible solutions? @coteyr suggested forcing the client to make multiple calls, which might work. I'm also considering using a 400, but adding a warning line in the response body saying that one of the errors might be on the server side. My 400 response bodies already try to list the specific client errors.