Just wondering what HTTP status code I should return for a REST api if the posted data already exists. Example if I have a create account API that requires an email.
1) If this email already exists on my DB, what status code should I return?
2) If I redirect to another page, like an existing account login page, should the status code then be 200? or 300 for redirection?
If this question has been answered, please just give me the link and I can delete this, but so far I only saw questions for invalid data.
This post suggests to use the 409 Conflict status code when duplicated data is submitted.
Related
I was thinking 403. From http://www.restapitutorial.com/httpstatuscodes.html:
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
Edit: Endpoint - POST /users.
The normal HTTP error code for situations like this is 409 Conflict:
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
This should be issued in response to a POST or PUT, typically as part of some sort of RESTful API. It should include a useful error message in addition to the status, and the error should be appropriately encoded (e.g. with XML or JSON).
Obscure HTTP errors are less useful in front-end web services. If you are developing a user-facing website, it's preferable to simply deliver an HTML page explaining the problem with a standard 200 OK.
If you are creating a REST API to create accounts, I would expect the request to be something like:
POST /accounts HTTP/1.1
{userid: "someone#example.com", password: "passw0rd!"}
In this case, I guess an appropriate response code would be 409 Conflict with an error description in the body
HTTP/1.1 409 Conflict
{ error: "Account already exists"}
That status code is for an HTTP error, not what you need. Also, it would be very unhelpful as it does not describe the problem at all.
Why not just send:
Username already exists! Please select another.
403 is an ok response in my opinion. 409 and 412 are also possible choices.
I'm no expert in this so please tell me if I'm way off :)
I'm trying to define a REST service that handles accounts.
/Accounts/32 (GET to fetch one)
/Accounts (GET to fetch all)
And so on...
However, in the sign up process, before an account is created, I would like to verify a couple of fields, like E-mail and ssn, async before the account is created.
How should I go about doing so? I just want to know if they exist in a combination but I shouldn't get a resource back since it's none of my business. :)
Is it valid to do something like this?
/Accounts?ssn=123&email=a#email.com&operation=verifyexistance
Thanks
// Johan
Interesting question, for me I would prefer to do the following:
HEAD /accounts?ssn=123&email=a#email.com
if response status code is 200 then the resource exist on the server
if response status code is 404 then the resource not available and you can continue with registration
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.
I like Anas Salman's answer, which suggests the use of HEAD. That's the ideal method.
But I also think that GET is perfectly fine. You are requesting to get information about the resource (the /accounts collection).
GET /accounts?ssn=123&email=a#example.org
When /accounts sees a request in this format (a GET request with an SSN and email address provided), it has enough information to know to respond appropriately with an affirmative or negative.
The addition of an "operation" verb in the query string is the only unRESTFUL part of your example.
I have created myself a standard asp.net web api project and it has a Post on there.
The post basically will insert some values into a database but before doing so I need to do a number of different checks on an alternative database, if anything doesn't check out I want to return the client with a NON 200 http status code but which should I use?
What is the recommended status code to return? I would also like to return some text with it which would contain additional information that could identify what the error was.
Or is it recommended to return 200 and an additional JSON payload identifying if there was a problem and what it is
Does anyone have any examples??
Thanks in advance
400 BadRequest could be used if what you are performing is validation logic and this validation logic fails for some reason. As far as the additional information is concerned, you might return some info in the body, for example as JSON payload:
{
"errorMessage":"Validation failed because user doesn't exist in alternative database"
}
If on the other hand you are attempting to update an entity that doesn't exist, you could also send a 404 status code.
In addition to what Darin stated on this thread, here is a good reference on status codes. I have also found this article valuable in handling errors with ASP.NET WebAPI.
This started as a question, but in the process of posting this question, I solved it. So now, this is an FYI post...
==========
At first, whenever I tried to post to this URL, I would get an error message:
https:// www.dwolla.com/oauth/rest/register --> Bad URL
There is no operation listening for
http:// phx-dwol-web1.cloudworks.com/oauth/rest/register, but there is
an operation listening for
http:// www.dwolla.com/oauth/rest/register/, so you are being
redirected there.
I fixed by appending the auth values to the post URL:
https://www.dwolla.com/oauth/rest/register/?client_id={id}&client_secret={secret}
--> Good URL
Then, I was having trouble with request formatting. To fix this, make sure that you post JSON in the BODY of the post. Do NOT append to the URL, or submit as form fields.
Lastly, when I finally got a proper response from the Dwolla API, I was getting this error:
"New user must accept terms of service."
This is because the Dwolla API is CASE SENSITIVE, so the "ACCEPTTERMS" parameter in the JSON body must be submitted as "acceptTerms" in order for it to work.
Here is the documentation I am referencing:
http://developers.dwolla.com/dev/docs/register
Happy coding!
Thanks for the answer...it ultimately led to me solving my problem as well.
For completeness, I encountered this error when sending a poorly formed request to the api, where I had left off the trailing / before the get parameter {oauth_token}.
INCORRECT:
http://www.dwolla.com/oauth/rest/users?oauth_token={oauth_token}
CORRECT:
http://www.dwolla.com/oauth/rest/users/?oauth_token={oauth_token}
We have a login REST service:
POST /sessions
When the users password has expired the next thing that must happen is that the client application will present a change dialog window and then change the users password via:
PUT /users/_ID_/password
What is the best way to communicate this intent to the client? At first I wanted to have POST /sessions return See Other (303). But this causes a GET on /users/_ID_/password. I could return a Multiple Choices (300) response which the client does not do an automatic get on, or I could return an OK (200) and tag in the JSON session object returned.
Having a look at the HTTP status code definitions, I'm thinking the following is the best fit:
409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict and
resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem
There is a conflict with the current state of the session resource because the user needs to change their password before being able to create a session. You can return the url to the change password screen in this response so that the client knows where to go to fix the conflict.
At first I wanted to have POST /sessions return See Other (303).
This isn't correct. It would essentially be saying "Don't POST a session here, POST a session over there." You'd be relying on out-of-band information and hard-coded behaviour to recognise that this isn't the case and you should actually POST a new password there instead.
I could return a Multiple Choices (300) response which the client does not do an automatic get on
But you aren't offering multiple choices.
or I could return an OK (200) and tag in the JSON session object returned.
The POST wasn't successful, so you shouldn't respond with 200.
Are you really asking for the "correct REST response" or are you asking how to achieve a particular effect with HTTP? Because it seems you're looking for loopholes rather than the proper design.
If a request comes in and authorisation fails, then respond with 401 Unauthorized and a WWW-Authenticate header. Then use a custom authentication scheme that indicates the user needs to change their password.