0

We have POST API that gives particular user's contact details in response. But as this is confidential data, to access this detail, anyone accessing it needs to put verified mobile number.

The request looks like:

POST /api/userdetails
{
   "userid": 123,
   "mobile": "+1394839843"
}

What should be status code if "mobile" number is not a verified number in our database?

Sahil Sharma
  • 3,027
  • 3
  • 29
  • 71
  • Why would there be an HTTP status code for that specific scenario? – CodeCaster Aug 31 '17 at 17:47
  • I mean should we return Forbidden, badrequest in this case OR some other status code? – Sahil Sharma Aug 31 '17 at 17:52
  • Well you're asking about REST, and that doesn't go in one sentence with "POST API that gives [...] details in response". The status code is irrelevant, first find out whether you're actually creating a REST API before you bother about status codes. – CodeCaster Aug 31 '17 at 17:58
  • because this API inserts record in database i.e. X number has viewed details of Y, hence we are using POST here. – Sahil Sharma Aug 31 '17 at 18:01
  • I think they are asking why are you saying it's a request if it's creating data? Shouldn't it be a POST (or PUT if it's an overwrite to existing information)? See http://restcookbook.com/HTTP%20Methods/put-vs-post/#sthash.u3S9tnPo.dpuf – TheFiddlerWins Aug 31 '17 at 18:41

1 Answers1

1

What should be status code if "mobile" number is not a verified number in our database?

From a very high level: think about what you would expect a plain old web site to do if a user submitted a form with a "not verified number" and do that.

The charts in Michael Kropat's Stop Making It Hard breaks the process down into more specific questions.

Is there a problem with the request? That's clearly a yes, here, so we know immediately that you'll want to use some code from the 4xx class.

From there, it's just a matter of looking through the semantics of each code and seeing which one best fits.

400 Bad Request is the generic client error, so you use that if you can't find a better match.

403 Forbidden is roughly "I understand your request, but decline to act upon it." This is most commonly associated with authentication and ACLs, but the standard doesn't actually require that. Given your description, it's not a bad match.

422 Unprocessable Entity from WebDav, is another possibility. I'd reject it, on the grounds that the schema of the message body is perfectly correct, the problem is that the specified value isn't aligned with the current state of the server. You might want to review a previous discussion about 400 vs 422

VoiceOfUnreason
  • 40,245
  • 4
  • 34
  • 73