For a get method, I get a response as Unexpected 'C' on Postman with a request header set Accept = application/json. The produces type is application/json in the rest controller. I would get a 406 error if I don't have the header setting. I have a right response data in a browser.
What is the "Unexpected 'C'" about? And how can I get rid of it?
Update:
I run into a similar problem again today. I attach a screenshot to this question. The error will go away once I remove the Accept in the request header.
The expected response is JSON format and you probably write in response a regular string which start with 'C' or 'H'.
Try whether to Create JSON and send it back in response or erase Accept and ContentType application/json and send regular String in response.
Related
on hitting the API request using GET method, i get the response content-type as text/plain; and it is a token (example:- ejusgjksdflksdfkjdfksdhfkds). how to store this response token to a variable using script in postman.
Any test script for this?
Thanks.
derived from #danny's answer in the comments,
use pm.response.text() when the response header type is text/plain.
ex:
pm.globals.set("my-token", pm.response.text());
console.log(pm.globals.get("my-token")); // the variable value will outputs to postman console
I have setup a mock server in Postman.
For a request X, I have added 2 examples (responses)
200 Success Response
400 Bad request
When I use x-mock-response-code I am able to get the appropriate response.
But when I dont use the x-mock-response-code, I am always getting 400 Bad Request. I am expecting 200 by default. But its not happening.
Do I need to add some thing to example response ? I tried to change example name as Default but no use..
If your example requests are identical, Postman will deterministically return the response for one of them. There is no concept of 'default' examples at this time.
If you want a particular response to be returned, make sure your example requests are not identical and only one example request matches the request you are sending.
Or use the x-mock-response-code header as you are already doing.
I have an API Gateway POST endpoint that takes in a JSON request body. I have turned on the body request validator and added the request body model. However the error response I'm getting is only some generic message: "message": "Invalid request body" as defined in the Gateway responses. I'm wondering if it is possible to include the specific validation error in the response? In the logs it says specifically
Request body does not match model schema for content type application/json:
[object has missing required properties (["property1","property2",...])]
Is it possible to have something similar to this in the actual response? Thank you.
In Gateway response for error type BAD_REQUEST_BODY error status 400
set Application/json to {"message":$context.error.validationErrorString}
Ref
https://stackoverflow.com/a/48014686
AWS API Gateway will include more details only if the request payload format is valid, but parameters format is invalid:
{
"message": "Missing required request parameters: [p1]"
}
If the request payload is invalid, you will always receive the same message:
{
"message": "Invalid request body"
}
See the bottom of following page:
http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-validation-test.html
The only way you can get more details is through logs.
By the way, why do you want to send more details through your API, is it for development and debugging only? If yes, using logs is the way to go. You may have some log processing and storage solution to make your debugging easier (e.g. Splunk, Data Dog, Sumo Logic, etc.)
Otherwise, in general, returning too much of technical details in your API error messages is something to avoid.
I am using JSONAPIAdapter in Ember Data, in case server wants to reject the request, server returns HTTP status code 400 Bad Request with json payload like this:
{"errors":[{"code":"698","title":"Invalid request"}]}
According to the jsonapi.org, I think this is the correct format( a array of error objects keyed by "errors" )
But when I run Ember, I always get a Adapter error. Is my format incorrect?
Getting AdapterError is correct behavior in this case. You can see that your payload from the server is correctly parsed by Ember and errors property of Error object you've logged is populated.
So, your adapter tries for example to get some records, but instead it gets 400 error and it's expected that you will get AdapterError.
If you don't want to get AdapterError you have to change the way your server behaves and instead of rejecting request provide model data.
You can also catch AdapterError if this is expected for you and handle that manually.
I'm implementing an API. The API accepts/returns JSON content type.
Now, suppose that the data submitted by some POST request is not valid, like a missing attribute, or a duplication exists for the same data.
What is the standard HTML response code in that case?
The error lies on the client side, so you want to use a 4xx status code. I'd go with 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.
There are two answers:
If you have submitted a form, just return 200 - OK with HTML explaining why the object was not created.
If you have an API you should use the following
200 OK
When the request was OK and returned the proper data.
201 CREATED
The call was successful and the new object created.
400 BAD REQUEST
Invalid request URI
Invalid HTTP Header
Receiving an unsupported, nonstandard parameter
Receiving an invalid HTTP Message Body
401 UNAUTHORIZED
Authorization problems. E.g. wrong API key, etc.
403 FORBIDDEN
Properly authorized, but not allowed.
404 NOT FOUND
The resource does not exist (e.g. on Read or Update)
405 METHOD NOT ALLOWED
Use in situations that a given REST method is not allowed. E.g. a POST on a single resource, or a DELETE on the entire collection of resources.
409 CONFLICT
When an update fails, send "Conflict" to allow the client side to resolve the conflict themselves and retry.
500 INTERNAL SERVER ERROR
Internal error. This is the default code that is used for all unrecognized errors.
501 NOT IMPLEMENTED
Use for expected, but not yet implemented features.
The closest i can find would be 400 Bad Request.
As Ariejan said you should base your API in the HTTP codes already defined. If you want to send a error message the best way should be not use the HTTP message, but better include the message in the response body, JSON formatted.
422 Unprocessable Entity (see RFC 4918, Section 11.2)