I am implementing a REST API and i have a set_ftp_credentials request
for example
POST api.domain.com/object/set_ftp_credentials
This request checks that the ftp credentials are good by trying to connect.
We had a discussion here whether we should return a HTTP response 200 and in the content
return the the request have failed and the reason.
Or we should return some other HTTP response code (40* response code).
What is considered the right way of doing this ?
And if not 200 then what do you think is the right response code ?
I believe that 200 is an OK response and should only be sent when the request was successfully satisfied.
One approach would be to answer the following questions for yourself:
What HTTP methods are you supporting?
What is the expected behavior of each HTTP method?
For each supported HTTP method, What are the possible classes of failures that can result if something goes wrong?
Now, return your expected response pay load with a 200 HTTP response code. Return client side error (400 class) or server side error (500 class) for the failures.
You might want to consider the following:
Return error codes that are specific to your application and map them to HTTP error codes
Have separate data contracts (assuming JSON format or XML schema) defined for successful response and error responses
Related
I am solving one question with my team about REST API specification.
We have a case where in some requests we are sending only some particular command via HTTP request for example : We are using POST (now considering PATCH request) to endpoint : /server/startSomeOperation . Backend developers told us that this request is only telling hardware to start some functionality on backend that affects the measurement of the user but it really has nothing to return. My question is :
Should we (according to some REST API specification) always return body of such a request when we know that no additional returned data will be needed except HTTP status code? Until now we were strictly following the rule that every request needs to have some sort of body returned but until now every body response even when it was a command to a server made sense.
Should we (according to some REST API specification) always return body of such a request when we know that no additional returned data will be needed except HTTP status code?
No - it is perfectly fine to send a 204 No Content or a 205 Reset Content when the semantics of your response is well aligned with the standard meaning of those codes.
You also have the option of declaring that the "representation of the status of, or results obtained from, the action" is zero bytes long, in which case you could use a 200 OK with a Content-Length header.
Do we have a list of possible reason codes from BigQueryError.getReason() https://googleapis.github.io/google-cloud-java/google-cloud-clients/apidocs/index.html?com/google/cloud/bigquery/package-summary.html ?
BigQueryError is a java class from Google's BigQuery client lib.
We are streaming inserting rows to BigQuery. Would like to know under what kind of reason codes, we can retry the insertion.
Thanks
You can find the BigQuery error codes in the following page
https://cloud.google.com/bigquery/troubleshooting-errors
One important point for HTTP errors from the documentation (not listed in the doc)
If you receive an HTTP response code that doesn't appear in the list
below, the response code indicates an issue or an expected result with
the HTTP request. For example, a 502 error indicates there is an issue
with your network connection. For a full list of HTTP response codes,
see HTTP response codes.
is there a way to 'tag' each API in jmeter so that I could specify which response from each API is expected?
For example, if not logged in - some API's give 500 error, and some still give 200. I would like to specify, which API's should give response 500 back (response 200 would be an error), and which still can give 200 (for those APIs response 200 is OK). Thanks!
For those API endpoints which should return HTTP Status code 200:
Add Response Assertion as a child of the HTTP Request
Configure it as follows:
Response Field to Test: Response Code
Pattern Matching Rules: Equals
Patterns to Test: 200
For those API endpoints which should return HTTP Status code 500:
Add Response Assertion as a child of the HTTP Request
Configure it as follows:
Response Field to Test: Response Code
Pattern Matching Rules: Equals
Patterns to Test: 500
Check Ignore Status box
See How to Use JMeter Assertions in Three Easy Steps to learn more about JMeter assertions, where to put, when to use, what is the impact, etc.
I am developing a RESTful API. I am confused about setting HTTP status code in this particular scenario. I am not sure what status code should I (server) return.
Let's say my app has a follow user functionality, if I am already following a user and again I send follow request for the same user id then in this case what should be the HTTP status code from server. The status code will be followed by an error message saying something like: "already following the user."
Similar scenario can be considered for unfollow user functionality, if I am not following an user "A", still I send request to unfollow user "A", then what HTTP status code should server return with error message something like "not following user to unfollow"
Certainly 200 response code doesn't seem to be appropriate to me here? or does it?
Please forgive me if I have posted the question at wrong stack exchange site, I posted it in stackoverflow site just because it is related to REST APIs.
EDIT
From client side user needs to send POST request to the URL:
http://www.myserver.com/api/follow/10
along with other necessary parameters ( like API keys, proper headers, etc) which are used for authentication before serving the requests at server side.
similar URL for unfollow action is:
http://www.myserver.com/api/unfollow/10
Right now, I am sending HTTP status code 200 in response if the client sends follow request, let's say, for user id 10 even if he/she is already following the user with id 10. In this case,along with status code (200) I am sending message similar to "already following the user"
Somehow I feel this is not convincing as no resource is created/updated it should return the error message with proper status code something other than 200, may be one from 4XX, not sure.
422 Unprocessable Entity
422 seems to be the proper HTTP status code in this use case.
The description of 422 says:
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions.
The answer depends on your API. You're describing the API in terms of "follow user X" or "unfollow user Y". That makes me think you might be approaching your API design in an RPC style rather than focusing on resources.
If your API uses REST including the HATEOAS principle, then error codes from the 4xx range may be appropriate (but I would recommend against it in this case, see below). In very short: HATEOAS means that your resources provide links to possible "actions". You can read more about it here: http://restcookbook.com/Basics/hateoas/
Apart from that, it seems a good idea to design your API "fault tolerant", i.e. expect the same request sent multiple times (e.g. because users are impatient and click again and again, or the browser crashed and is restarted and reopens all previous tabs, or...).
My personal opinion and recommendation is the following:
follow user X: Your implementation should check if it needs to add the new follower or not. Regardless, if the user is already following or not, send back HTTP status 201 (created) and add the "Location" HTTP header pointing at the resource.
unfollow user X: Your implementation should check if it needs to delete the follower or not. Regardless, if the user is already removed from the followers or not, send back HTTP status 200 (OK).
The general idea is, if a client requests something to be a certain way and that is already the case, the server has two options: Either it responds to the client "The result you wish is already in place. Therefore your request is invalid." or the server can respond "The result you wish is already in place. You have everything you need.".
Going for the second option makes the API more tolerant and helps with idempotency (see http://restcookbook.com/HTTP%20Methods/idempotency/).
I think djlauk's answer covers a lot, but I want to give a little different approach and add some information:
Do not use verbs in the URI
I would not use POST on /follow/ respectively /unfollow/ URIs because this is not very RESTful see this SO question: Why does including an action verb in the URI in a REST implementation violate the protocol? and escpacially this SO answer: How to create REST URLs without verbs?
Do use the correct HTTP verbs for the actions
What you want to do is a creation of an entity ("follow") so for that you can use the HTTP verbs POST or PUT and afterwards the deletion of that entity ("unfollow") where DELETE would be the right fit.
My approach for your API:
I would do the following:
(The first two examples are just for explaining the structure, you don't have to implement them if you don't need them.)
This does get you the user "robert":
GET http://www.myserver.com/api/users/robert/
response: #200
This does get you the users "robert" is following:
GET http://www.myserver.com/api/users/robert/following/
response: #200
And this is how you let "robert" follow "rahul":
PUT http://www.myserver.com/api/users/robert/following/rahul
response: #200
If you send this request again you get the same response:#200 because PUT is idempotent and this is how it should behave (see (2))
When you now want to let "robert" unfollow "rahul" you send:
DELETE http://www.myserver.com/api/users/robert/following/rahul
response: #200
If you send the DELETE request again you get a little different response a #404 , but this is HTTP standard and the clients should understand this.
For the regular answer codes of HTTP methods I can also recommend this source: restapitutorial.com
I would use some of the following:
System.Net.HttpStatusCode.ServiceUnavailable;
System.Net.HttpStatusCode.MethodNotAllowed;
System.Net.HttpStatusCode.BadRequest;
Better if it is one of the first two.
Certainly 200 response code will not work in this situation.
following are the groups in HTTP Status Code:
1xx Informational
2xx Success
3xx Redirection
4xx Client Error
5xx Server Error
Certainly you need to use 4xx.
I think for the condition that you have described here, you can use any of the following:
405 Method Not Allowed
A request was made of a resource using a request method not supported by that resource; for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.
400 Bad Request
The server cannot or will not process the request due to something that is perceived to be a client error
409 Conflict
Indicates that the request could not be processed because of conflict in the request, such as an edit conflict in the case of multiple updates.
More details are available here:
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
not really sure where to start here other then to dive into CF (I REALLY don't want to do that) but....
I have an NSURLConnection signing OAuth2 requests to an ASP.NET WebAPI Resource Server, this resource server returns JSON body AND statusCode 400. I have yet to find a way to parse the data from the response when it returns code 400.
Does anyone here have any ideas? I would prefer to keep using NSURLConnection as this is only an OAuth2 consumer class. My other code is using restkit, but I do not want the OAuth2 end to require said library.
The process to parse data from a request which returns status 400 should be identical to that of a request returning status 200.
Simply note the status code in -connection:didReceiveResponse: and allow the request to continue; you will receive any additional data that the server sends in -connection:didReceiveData: as usual. Finally, you'll get a -connectionDidFinishLoading: call when all data has been received, and you can parse the JSON there.
Does your HTTP request Accept header specify "application/json"? If so, then this is probably an IIS bug and not iOS.
Interestingly enough, MVC4 ActionResult is broken in the RTM. Switching it over to Pure WebApi and fine tuning the response, I was able to finesse it into returning the proper data, it was likely serializing the json improperly which other languages weren't catching.