koral
koral

Reputation: 2965

RESTful API design - response http codes

I need to have 2 action calls using POST.

VerifyCerts doesn't required parameters. In backend it verifies if 2 files (uploaded earlier) are correct. What should I return in case of error? I mean should it be http status code 4xx or 200 and info about error in content?

ApllyCerts also doesn't required parameters. It tries to apply already uploaded cert files. What 4xx code should I return when there is an error (files incorrect)? And what should be in response body?

Upvotes: 0

Views: 78

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57397

VerifyCerts doesn't required parameters. In backend it verifies if 2 files (uploaded earlier) are correct. What should I return in case of error? I mean should it be http status code 4xx or 200 and info about error in content?

Remember, HTTP doesn't know anything about "action calls". It knows about resources, and representations of resources. But the implementation details are deliberately hidden.

Here, it sounds like you have a resource, and the representation of that resource is calculated from the data that has been stored on the server. So I would expect that response to be accompanied by a 2xx code, even when the 2 files are currently "invalid".

(There's no problem with the request, there's no problem with the server, you are just documenting that the state of the world isn't currently aligned with the happy path).

ApllyCerts also doesn't required parameters. It tries to apply already uploaded cert files. What 4xx code should I return when there is an error (files incorrect)? And what should be in response body?

The response body is the easy part -

Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.

The response code is harder. I think you can make reasonable arguments for 403 Forbidden and 409 Conflict; in effect, the client's request is an attempt to take the resource from state A to state B, but in fact the resource is currently in state Z which does not have a transition to state B.

In practice, I don't think it matters very much -- neither of those response codes are cachable by default, generic consumers don't have any particular reason to handle those code differently, and so on. The distinction in semantic meaning doesn't have any practical effect that I can see.

So if someone later persuades you to change which one you use, I don't think that generic clients will behave any differently.

Upvotes: 1

user1428716
user1428716

Reputation: 2136

Since these dont need any params means that Input is not required for Verification and ApplyCerts , the error should be 500

HTTP Status 500 Response body (json or text ) { Error_Code:"FileNOtFound"..etc }

Upvotes: 0

Related Questions