I wanted to know if there were any ways to have a POST call on my Play framework REST API without any JSON in the call.
I'm making the API with the logic that if you create anything in the database, then you need to make a POST call, but yet I have this issue that occurs right when it hits the API :
Bad Request
For request 'POST /promotions/add/user?userId=41375&promoId=24265'
[Invalid Json: No content to map due to end-of-input at [Source: akka.util.ByteIterator$ByteArrayIterator$$anon$1#a5de52b; line: 1, column: 0]]
Is there a way or I have to change the call in GET or make otherwise with userId and promoId in a JSON, which I would like to avoid.
Thanks !
Please check if you have set any content-type in the request. Also check how the requests are handled within the action method like using request.body.as<XXX> etc.
If your POST request is not using the json as the data payload, you may use a form to be bound from the request. In that case, make sure that you have set the Content-Type: application/x-www-form-urlencoded in the request. Sometimes, it doesn't matter you set proper content type header in request. It all depends on how POST request is handled by the controller action methods/API endpoints.
Related
I am trying to create a test plan using jmeter.its for an API Post request, I have a header manager, bodydata, checked for spellings and the syntax seems to be correct. However, Im getting 400 response code with the following error shown in the attached image. Anyone with an idea how I can resolve this? Thank you. the error
Here is the request the request
The user doesn't have to be logged in, i have added a header manager, I have also noticed there header has a cookie value thats hard coded but it appears to be the same in every request. In the UI the API request returns 200 and thats what im expecting with the Jmeter script.
In its current form the question cannot be answered comprehensively.
HTTP Status Code 400 means that
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).
Check that your ${site} and ${csVersion} variables have their respective values using Debug Sampler and View Results Tree listener combination
Cross check headers sent by JMeter and by the "UI", the most important is Content-Type
Use a sniffer tool like Wireshark of Fiddler and capture the requests which are being sent by JMeter and the "UI", the requests must be exactly the same apart from dynamic parameters which need to be correlated
The issues was being caused by an anti-forgery cookie which was hard coded in the request.I used a regex to extract the value from a previous request and used a variable value from the regex to make sure the same value is being passed on to the request that was failing.
When I test with Advanced Rest Client(Arc) all nine API calls to REST API works fine.
I use method Get with two headers the first is Authorization Bearer
the second one is Content-type application/json. It works even if I remove
header Content-type application/json
Here is a screenshot of the response from Arc. This same REST API call give error from Azure Data Factory(ADF).
Sceenshot from Arc
I call nine REST API from Azure Data Factory(ADF) with the same base url but different Relative URL.
Out of these nine 6 works perfect.
When I use Azure Data Factory(ADF) I use additional header
Authorization Bearer #{activity('GetToken').output.access}
What is strange is that the exact same call from Arc works fine but I get error when I call from ADF. Note also that I get the exact same error if I remove the additional header
Authorization Bearer #{activity('GetToken').output.access}
I mean that the code in REST API doesn't know if the call is comming from Arc or ADF.
Note also the the error is from the source side so my call to REST API with method GET
can't be handled by the REST API code for some reason.
According to the documentation for the REST API it says that
Headers Content-type application/json and
Authorization Bearer
I tried to add a second additional header in ADF Headers Content-type application/json
but I get REST connector ignores any "Content-Type" header specified in additional headers when request body is empty.
I have tried to find any sensible information about my error but there no one that have had any similar. What I find very strange is that 6 Rest API calls works fine and the json that we receive when using Arc is valid.
I don't realy understand the error message when saying
Requested format \u0022application/json\u0022 is not supported
Supported MIME types are \u0022application/ld+json\u0022
Here is the complete error message I get Screen shot of error message for ADF
Your response data is JSON LD (Json linked data). Hence you are seeing this error.
To avoid this error use Content-Type header value as application/ld+json.
I'm not sure whether I should include success message in the response when I create an API server.
Like when you PUT something to the API server and the backend creates something successfully, you can get a response with 201 status code.
Does the API server should include a message like:
{
"message": "Successfully created."
}
as JSON in the response?
I agree with VoiceOfUnreason: it not is mandatory, but I usually return
{"status":"ok"}
If I need to return some content
{"status":"ok","result":{.....}}
And, in case an error occurs, I still prefer to return a 200 handling the error at the application level
{"status":"ko","errorMessage":"Something went wrong!"}
Fabio
Should REST API always return response with a message?
It's not required - we have 204 (No Content) and 205 (Reset Content) in the standard because there are cases where a response without a body makes sense.
But in common cases where we are sending a 200/201, I would expect to see a response body describing the status of the action
The 201 response content typically describes and links to the resource(s) created.
No for example, for 204 responses we must not include message body. {success: true} is redundant.
In practice (or should I say in later version of jquery), empty response for application/json content type raises error. I kind of understand the argument that because it's application/json it must have a valid json body. So, empty response for application/json content type would be 'null' or '{}' which are valid json.
There's another way which should work for jquery, that is not returning application/json for empty responses. Just use text/plain or something and make sure client can handle that type.
I am writing a http handler for a server and I am looking directly at the http requests when they come in from different clients. I can easily deal with normal http requests. The problem occurs when I get a GET or POST request. I do not know how to access the data from the GET or the POST therefore I cannot continue. Could someone please point me in the direction of some where which deals with the issue on how to access the data. Thanks in advance.
Answer:
to do this:
In a GET request the data comes in the URL itself therefore just parse the URL from the HTTP request and look for the question mark and the arguments.
For a POST request there are 2 different ways however the main one means that the arguments are put in the body of the request like this:
q=hello&v=world
The length is specified in the request as well so if you need it is under Content-Length:
Does JSON messages sent over HTTP in response to a URL request make it REST-compliant?
I believe it is not.
But I am not sure on the detailed reason.
If i have a well-organized website,which responds to URL requests with json representation payload - what does it need to do further to comply with RESTful or JAX-RS?
A simple concise explanation will be much appreciated
There is no restriction regarding the payload of messages in REST and using JSON format in HTTP responses isn't enough to make a service RESTful.
To make short (since it's what you asked for ;-)), what is really important in REST is to respect the HTTP operations (GET, POST, ...) are designed for, the concept of resources and their states (idempotence, ...), leverages headers and status codes, ...
The following link could give you hints about the way to implement a RESTful service / Web API:
Designing a Web API - https://templth.wordpress.com/2014/12/15/designing-a-web-api/
Hope it helps you,
Thierry
JSON is a payload and does not play any role in making your Webservice REST-complaint.
Payload could be XML, CSV, plain text etc etc.
The Webservice will be REST-Complaint when it's following REST protocol (set of rules, not network protocol).
There are up to 4 levels where you can make your REST webservice complaint to.
One of the very basic rules to understand is that - Your Request must not be RPC i.e. you MUST not perform any action using a Payload (Typical SOAP) or URL tunnelling e.g. http://www.example.com/product?id=1234&action=delete
In RESTful world you would define one top level URI for the above. e.g. http://www.example.com/product
and then you will call various URLs to perform other actions.
Such as:
POST - create Data
http://www.example.com/product
Body{ here your payload will describe the Product.}
Assuming you rely on server gennerated product id then return type could be Product Id. Which is again should be set as LOCATION parameter of the return header.
PUT - Update Data
http://www.example.com/product/1234
Body{ here your payload will contain the Product details to change.}
GET - Get Data
http://www.example.com/product/1234
DELETE - Delete Data
http://www.example.com/product/1234