Is returning request body along with error code(response) in case of invalid payload a standard practice ?
Request:
{ "payload" : " + request" }
in the above json "+" is not accepted character in my API, and server is returning an error message representing that request payload consists of invalid characters.
Response :
{"payload": " + request", "error":"Invalid character '+' in request payload"}
Above is the response being returned.
Note: Agreed it is inefficient to send request payload to and from, which is originated from the client.
Is returning request body along with error code(response) in case of invalid payload a standard practice ?
Somewhat - think about the forms that you see on the web; what happens when you submit a form, but the server thinks one or more of your values is invalid? Typically, you get a new representation of the form, with the problem fields highlighted.
It might be possible to build that kind of signal directly into a media type, but I don't think I could point you at a standard for doing that.
With application/problem+json, you've got some freedom with extension members that you could use to echo back the original data.
I get a request from
http://localhost:8080/hello-world/login?name=ilkin&password=pass
Response:
{"token":"b49cd24c-d35f-4c5c-aac5-9017b8d3641d"}
Now I need to use this token value and create another get request with it.
http://localhost:8080/hello-world/person?token=token
How can I do all of that with okhttp?
In my Ruby on Rails application I tried to upload an image through the POSTMAN REST client in Base64 format. When I POST the image I am getting a 406 Not Acceptable Response. When I checked my database, the image was there and was successfully saved.
What is the reason for this error, is there anything I need to specify in my header?
My request:
URL --- http://localhost:3000/exercises.json
Header:
Content-Type - application/json
Raw data:
{
"exercise": {
"subbodypart_ids": [
"1",
"2"
],
"name": "Exercise14"
},
"image_file_name": "Pressurebar Above.jpg",
"image":"******base64 Format*******"
}
Your operation did not fail.
Your backend service is saying that the response type it is returning is not provided in the Accept HTTP header in your Client request.
Ref: http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Find out the response (content type) returned by Service.
Provide this (content type) in your request Accept header.
http://en.wikipedia.org/wiki/HTTP_status_code -> 406
406 Not Acceptable
The resource identified by the request is only capable of generating response entities which have content characteristics not
acceptable according to the accept headers sent in the request.
406 happens when the server cannot respond with the accept-header specified in the request.
In your case it seems application/json for the response may not be acceptable to the server.
You mentioned you're using Ruby on Rails as a backend. You didn't post the code for the relevant method, but my guess is that it looks something like this:
def create
post = Post.create params[:post]
respond_to do |format|
format.json { render :json => post }
end
end
Change it to:
def create
post = Post.create params[:post])
render :json => post
end
And it will solve your problem. It worked for me :)
"Sometimes" this can mean that the server had an internal error, and wanted to respond with an error message (ex: 500 with JSON payload) but since the request headers didn't say it accepted JSON, it returns a 406 instead. Go figure. (in this case: spring boot webapp).
In which case, your operation did fail. But the failure message was obscured by another.
You can also receive a 406 response when invalid cookies are stored or referenced in the browser - for example, when running a Rails server in Dev mode locally.
If you happened to run two different projects on the same port, the browser might reference a cookie from a different localhost session.
This has happened to me...tripped me up for a minute. Looking in browser > Developer Mode > Network showed it.
const request = require('request');
const headers = {
'Accept': '*/*',
'User-Agent': 'request',
};
const options = {
url: "https://example.com/users/6",
headers: headers
};
request.get(options, (error, response, body) => {
console.log(response.body);
});
Changing header to Accept: */* resolved my issue and make sure you don't have any other Accept Header
In my case, I added:
Content-Type: application/x-www-form-urlencoded
solved my problem completely.
If you are using 'request.js' you might use the following:
var options = {
url: 'localhost',
method: 'GET',
headers:{
Accept: '*/*'
}
}
request(options, function (error, response, body) {
...
})
In my case for a API in .NET-Core, the api is set to work with XML (by default is set to response with JSON), so I add this annotation in my Controller :
[Produces("application/xml")]
public class MyController : ControllerBase {...}
Thank you for putting me on the path !
It could also be due to a firewall blocking the request. In my case the request payload contained string properties - "like %abc%" and ampersand symbol "&" - which caused the firewall to think it is a security risk (eg. a sql injection attack) and it blocked the request. Note here the request does not actually go to the server but is returned at the firewall level itself.
In my case, there were no application server logs generated so I knew that the request did not actually reach the server and was blocked before that. The logs that helped me were Web application firewall (WAF) logs.
In our running application, one of GET request starts giving response as 400 Bad Request in Internet Explorer.
On investigating , I found that GET request doesn't have queryParameters what were expected by ReST call.
As it is giving response in another browsers like Chrome, Mozilla,
how can I proceed further ?
this is Request currently being triggered--
Method of request is GET
https://XXXXXXXXX/XXX/XXXXXXXXX/XXXXXXXXX/XXXXXXXXX/XXXXXXXXX?{%22numRecords%22:1000,%22start%22:0}&_=1487576597960
and queryParameters in #QueryParam expected by ReST api are-
-numRecords
-start
I know by the above GET request, numRecords and start will not get captured by api backend.
So , is there any chance, if my GET request lack of any #QueryParam will lead to 400 Bad request response.
I found that GET request doesn't have queryParameters
You can use query parameters in GET requests as you've provided in your example like this: http://host?queryParam1=value1. however it's not possible to pass a request body as you can do for POST or PUT requests to provide JSON encoded data for example. You can work around this by adding the JSON AND URL encoded payload to a query parameter. But you endpoint explicitely has to be able to read this parameter. So you should add this parameter to your definiotn like in this example for JAX-RS:
#GET
#Path("my-endpoint")
public String request(
#PathParam("payload") JsonObject payload
) {
What you've tried is to simply pass the payload data without specifing the name of the request parameter.
Hope this helps.
im writing a java application that sends a post request to a server and expect a json from the server. Now when i need to get the response from the server do i only need to get it from the inputStream when the http code is 200 (HTTP OK) or is there any other cases ? , example :
//...
if (urlConn.getResponseCode() == HttpURLConnection.HTTP_OK) {
// only here try to get the response
}
//...
It depends on how the server is implemented. Check the API, if the server has one. If it's internal, ask your server guy.
Generally speaking, if your response code is either 2xx or 3xx, I would check the response anyway...
If the server your communicating with is following the spec then either 200 or 201 responses are valid to contain an entity. A 204 response is successful but has no data in the response.
See section 9.5 here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 for details of acceptable responses to a POST. Extract below:
The action performed by the POST method might not result in a resource
that can be identified by a URI. In this case, either 200 (OK) or 204
(No Content) is the appropriate response status, depending on whether
or not the response includes an entity that describes the result.
If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location
header (see section 14.30).
There are three things to consider:
All 2xx codes denote success of some sort. But depending on the exact code, your reading code might be different. (204 for example means success but no content.)
There are redirecting codes (3xx). These are usually automatically followed by the http client library but you can also set them not to, in which case you need to have custom code that handles these cases.
There can be valuable information returned in the stream even if you get a code that denotes an error. Whether you want to process it depends on your exact needs.