I am sending a PERL POST Request over HTTPS. During sending the request i need to send two things in content one is an authorization token and other is the command need to be executed on the server side.
What should be the approach to send these two things as the content?
Should it be:-
$request->content($token)
$request->content($command)
OR should it be
my #content =($token,$command)
$request->content(\#content)
The module which i am using is LWP::UserAgent and in that i will be creating a HTTP::Request type object my $request = HTTP::Request->new(POST => "<url>"); and in
this object i am sending content.
There is only a single content (request body) for a POST request. So any call of content just replaces the previously defined content. Please have a look at the documentation for LWP::UserAgent::post which clearly defines how to send POST data with multiple values. Also, it might be useful if you understand how forms in HTML work, both on the client (browser) and on the server side. Because only if you know what the server side expects in detail you can create the proper request.
Related
Is it recommended to send a JSON body via a POST HTTP Request which doesn't modify anything?
Based on the link below, a Get request is not recommended to have a body. Thus, the other way is the one above.
HTTP GET with request body
Example:
Get the list of users, or anything for that matter based on parameters.
Http GET example.com/users
Body
{
name:"John",
age:1,
... long list of parameters
}
Is it recommended to send a JSON body via a POST HTTP Request which doesn't modify anything?
The rule is that POST is the default; it should be used unless there is something better.
For a request with "effectively read only" semantics, you want to use GET instead of POST... if it works. The challenge can be those cases where the request-target (aka: the URI) gets long enough that you start running into 414 URI Too Long responses. If your identifier is long enough that general purpose components refuse to pass the request along, then it is not something better, and you fall back to POST.
An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. (HTTP Semantics, 9.3.1)
In other words, introducing a private agreement to include content in a GET request trades away inter-op, which - if you want "web scale" - is not a winning trade. So GET-with-a-body is not better, and you fall back to POST.
The HTTP working group has been working on semantics for a new "effectively-read-only-with-a-body" method token, which could prove to be an alternative for requests where you need to include a bunch of information in the body because it is too long to encode it into the URI. But we don't have a standard for that today, which means that it is not something better, and you fall back to POST.
This question already has answers here:
HTTP GET with request body
(23 answers)
Closed 2 years ago.
I've been looking at how to implement the following:
I am developing a RESTful Web API (using .Net Core 2.2). I need to create an endpoint where the consuming client can send some text to the API, the API replaces some tokens in this text, and returns the text back to the consuming client.
I thought that the client should simply do a GET request, with the text in the body. The reply would then be the new text after the token replacements. However, from my research, it appears one should not stick anything with semantics in the body of a GET request. I'm not sure if arbitrary text with certain tokens that need to be replaced by the API qualifies as semantic? I've also seen it stated at "you should not be able to use the body of a GET request to alter the response". I guess I'm in trouble there, as depending what goes into he body, will affect the response.
So then, I've been struggling to figure out what is the correct way to do this. If anyone has an pointers I'd greatly appreciate it.
Thank you.
I thought that the client should simply do a GET request, with the text in the body. The reply would then be the new text after the token replacements. However, from my research, it appears one should not stick anything with semantics in the body of a GET request.
Right - RFC 7231
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
In basic HTTP, you've got choices. One is to include a representation of your document in the URI itself
/?your_document_as_a_query_string
/your/document/as/path/segments
For short documents, that approach can be fine; but implementations are not required to support infinitely long identifiers, so you may discover that intermediate components reject your request, or crop the URI in transit.
A safe mechanism for achieving your goal is to use POST, rather than GET. POST supports a message body, so you can send the blank form to the server, and receive back the edited version in the response.
POST is the wildcard method of HTTP, it can mean anything. In the spec, the body of the response includes "a representation of the status of, or results obtained from, the action".
You might also consider that the response duplicates a lot of the content of the body of the request, and consider instead the possibilities of fetching a map of your template values from the server, and then applying the template on the client.
I am working on REST API with oauth2 authorization.
For Oauth2 server i use https://github.com/bshaffer/oauth2-server-php
Php doc says here http://php.net/manual/en/wrappers.php.php
Prior to PHP 5.6, a stream opened with php://input could only be read once; the stream did not support seek operations. However, depending on the SAPI implementation, it may be possible to open another php://input stream and restart reading. This is only possible if the request body data has been saved. Typically, this is the case for POST requests, but not other request methods, such as PUT or PROPFIND.
In short it means that it is possible to read POST body twice, but not PUT.
But Oauth2 server reads it first time here https://github.com/bshaffer/oauth2-server-php/blob/develop/src/OAuth2/Request.php#L114
So when i read raw body in Yii2 Request, it is empty. (only on PUT, on POST and PATCH it is ok and can be read twice).
https://github.com/yiisoft/yii2/blob/master/framework/web/Request.php#L345
I know that this is kind of expected, no bugs. But what would be the solution for this?
Before you create that auth server, run this (depending in where you do authentication, you can use beforeAction(), or even init():
$content = Yii::$app->request->rawBody;
$authentication = Request::createFromGlobals();
if ($content)
$authentication->content = $content;
Now, I don't know how/where you use the component, so it might not fully work, but in theory it should.
I am designing a RESTful API when I noticed something strange.
When I make a POST request for creating a new record, the form data is sent in request payload.
But when I make a PUT request to update a record, it appends form data in the URL, very similar to GET request.
Now a URL has certain length limit. So what would happen if PUT request has larger data than this limit.
Will the PUT request fail?
Is it unsafe to use PUT instead of POST to update a record having large form data?
EDIT:
I am using NodeJS server. I am using restangular(angular framework) to build my PUT request.
Use customPUT to send the form data in payload.
baseObj.customPUT(newObj).then(function(xyz){})
Have a look at these threads
Can HTTP PUT request have application/x-www-form-urlencoded as the Content-Type?
PHP multipart form data PUT request?
application/x-www-form-urlencoded or multipart/form-data?
Sounds like you can basically set a Content-type: multipart/form-data header and be golden. Basically comes down to configuration of the request with restangular and support thereof on the NodeJS server.
I got this problem, I have built a rest api and I don't know how to deal with this:
When the javascript client (Marionette.js) is in charge of making the views, I don't have problems, because as it is known, it just requests an url (e.g. example.com/user/37), the server retrieves a json with {id:'37', name:'Peter', age:'24'} (there is one controller class named User) and Marionette shows that data in the view. But if the user enter to example.com/user/37 by the browser it will show just {id:'37', name:'Peter', age:'24'} without any view. What can I do if I want to see the same view in both cases?
If you're trying to serve up HTML or JSON from the same endpoint then your server should be making that decision based on the request's Accept header. If the request's Accept header is application/json then your server should return just the JSON ortherwise return the HTML.
You can see that SoundCloud uses the same technique for returning XML or JSON from their API:
Resources are returned as XML by default, or JSON if a .json extension is appended to the resource URI. We encourage you to use JSON. You can also send an appropriate Accept header specifying the format you would like. For example, a request with the header Accept: application/json will return resources represented as a JSON document.
What you are trying to do is pratically impossible.
why ?
When your first enter the url example.com it's the server that responds with all the artifacts that compose your application (html, js, css ...) and the browser display it.
Now, when you enter ther url example.com/user/37 the server only sends the JSON data without any html, js or css, so the browser display the raw data he received.
What you are trying to do is to force the server to give two responses (JSON or html/js/css) depending on the user request.
You can do it, but it would be so complicated that's not worth the efforts.