I have the following rest request that works:
And the following one that doesn't work:
And here is the the response from the bad message:
The bad response was run through PowerShell but it shouldn't matter as I can see everything that is getting sent in Fiddler.
Can anyone spot what I have done wrong in the bad request?
Related
When I develop POST api, I used POSTMAN I create following request
But it seems send empty request to servers.
When I check server, the following error was displayed
Error: data and salt arguments required
It means empty body was send via POSTMAN
On the other hand ,When I tried
curl --data "loginId=hikaru&password=test" http://localhost:3000/user
following error was occured but some data was send and reached
ER_NO_DEFAULT_FOR_FIELD: Field 'firstName' doesn't have a default value
So what is the difference between POSTMAN and command ?
What is the wrong point of postman
I'd like to fix it.
If someone has opinion,please let me know.
Thanks
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
I'm trying to get my access token for my application, using this URL:
https://datamarket.accesscontrol.windows.net/v2/OAuth2-13?grant_type=client_credentials&client_id=//CLIENT ID//&client_secret=//CLIENT SECRET//=&scope=http://api.microsofttranslator.com
Obviously I replace //CLIENT ID// and //CLIENT SECRET// with my applications information.
I tried encoding the tokens with HtmlEncode in my application but got a 400 error. So I tried the request in my browser and this is the JSON response I got:
{
"error":"invalid_request",
"error_description":"ACS90007: Request method not allowed. \r\nTrace ID: 2144c829-f3fa-4ed8-80e6-40841e6a3f69\r\nTimestamp: 2012-06-27 01:11:27Z"
}
I don't know what I'm doing wrong, any help?
I believe when you are making the WebRequest call your parameter is set to use GET and this will cause error ACS90007. When making the WebRequest call please use POST along with application/x-www-form-urlencoded set Content-Type.
If you still have problem post your WebRquest code snippet and i will take a look.
It would be better if you can provide the code for AdmAuthentication. For now, please make sure you have correctly translated the code on http://msdn.microsoft.com/en-us/library/hh454950 to VB. Please also try to use Fiddler to monitor the request to ensure it is sending a POST request.
Best Regards,
Ming Xu.
Making my own client secret helped my cause
I read What HTTP status response code should I use if the request is missing a required parameter? but it did not specifically ask about headers and there didn't seem to be a consensus.
The context of this question assumes successful authentication. I'm currently favoring either a 400 (though that doesn't feel right because this isn't really a case of "malformed syntax") or 403. Given 403's description:
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.
This makes the most sense to me.
Can someone please enlighten me? Thanks.
400 Bad Request
It's a user error in the request. Unlike with a 403, the client should be allowed to repeat their request, but only after modification:
10.4.1 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
Edit
As Mark Reed points out in the comments, a 403 says, "There is nothing wrong with what you sent me. You have proper authorization and the syntax was valid. I just don't want to do what you ask."
The part that you have in bold simply says, if the server so chooses, it can tell the client exactly why it doesn't want to fulfill the request.
Consider simple case where user is deleting a post. This is simple HTTP DELETE/POST request with one mandatory field, post_id.
What should server do if post_id is not provided?
Apparently, user should never encounter this behaviour, so let's be puristic.
My first take would be 400 bad request, but spec says
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
and I'd say missing field is OK from syntax/http POV, it's application domain-specific semantic requirement.
200 OK with explanations is bad, 500 feels weird as this is request problem.
Thoughs?
400 is the correct response.
400 is not restricted to a malformed syntax from an HTTP point of view. Missing a mandatory argument is an error in the syntax defined by the application and thus a "Bad Request"
EDIT
At first it seems strange that there is no separate return code for this, but the return codes are designed to differentiate in what actions the client should take. A 400 error code means that the client should change the POST data or query string to the format defined by the application. Hence it is appropriate for this case.
In a REST scenario, the resource to be deleted should be identified by the URL, so the ID of the resource should be a part of that URL in order to properly identify it. Once that assumption is correct, then the URL either is identifying a different resource fr deletion, or it isn't (which would give a 404)
In the general case of a missing parameter, however, I often use a 403 Forbidden error. The reasoning is that the request was understood, but I'm not going to do as asked (because things are wrong). The response entity explains what is wrong, so if the response is an HTML page, the error messages are in the page. If it's a JSON or XML response, the error information is in there.
From rfc2616:
10.4.4 403 Forbidden
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.