The Mojolicious has two methods to access POST body: body_params and json
What is the benefit of them?
UPDATE
I think, it will be more handy if body_params returns hash if body is recognized by some parser and body_type will return the name of this parser.
Thus if it were POST from form body_type will return application/x-www-form-urlencoded
I cannot tell you why this decision was made. You'd have to ask SRI for that. He added the json method in 2010.
But I can tell you why it is useful.
body_params parses requests for common form submissions, application/x-www-form-urlencoded and multipart/form-data. You use that when your action talks to an HTML form submission or similar.
json on the other hand automatically decodes JSON data from the body. This is useful for AJAXJ requests and APIs. Typically it's used in a REST context where the client sends JSON encoded information. It decodes the JSON directly, making your live easy for you.
Related
I'm in a situation where the server has some items that are identified by two keys: type and size. Clients don't know the items ID.
Clients should be able to perform a request to get a list of the items they want. e.g.:
"Give me the circle 40, the circle 30 and the square 40".
That's easy with a json body, but we must use a GET request. Given the problem this is not useful at all: /ids=1,2,3.
Should we make a:
Bizarre convention that clients should send type_size?
Still bizarre convention that clients should send type=size1,size2
GET request for every type?
POST request to act as a GET?
POST request that generates an ID to perform a subsequent GET
request?
How would you do this with an HTML web page?
You'd probably have a web page with a form, the form would have input controls so that the client can list the items they want. When the are finished filling in the form, the submit it.
At that point, the browser uses the data collected by the input controls to create an application/x-www-form-urlencoded document, and (because the method on the form is GET), use that document as the query part of the request uri.
GET /items?circle=30&circle=40&square=40
More generally, we can provide to the client a URI template that describes how information should be encoded into the URI.
But as far as HTTP is concerned: as long as the URI conforms to the production rules described by RFC 3986, it can be anything you want. As long as the client understands how to encode the information, and the server knows to decode the information the same way, you can do what you like.
I am trying to get the form data from a multipart/form-data POST to my ASW Lambda web service via API Gateway.
The HTTP POST has Content-Type "multipart/form-data" and body that is URL encoded. File data is also sent in this post (hence the multipart, I guess).
The web service needs to integrate with a thirdparty service, so changing the format of the POST isn't really an option.
I have seen this thread talking about converting the URL encoded data to JSON object for use in Lambda, but this doesn't do the trick.
I have also tried setting the Integration Request -> Mapping Templates for content type multipart/form-data to Input passthrough. This didn't help either.
I did come across another question about uploading a file using multipart/form-data, but since I'm not interested in the file, just the body, that answer didn't help.
Below find screenshot (sorry) of the captured post via runscope.
If the goal is to use Lambda, you'll need to pass valid JSON to the function. Currently there isn't a way to JSON-ify data inside Api Gateway that comes in as non-JSON data.
Our short term fix (on our backlog) is to provide a variable in the mapping templates to grab the raw input of the request. That way you could do a simple JSON conversion using a template like:
{
"body" : "$input.body"
}
or something like that.
Check out the mapping template reference for more info: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html
Edit 4/7 - feature has been released as $input.body
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.
Hi,
I am a newbie to Backbone, My Rest Server Components Accept Only XML Requests, can Anybody show an example how do i send a xml to a rest api put request.
Backbone uses JSON by default, so to use XML you need to overwrite Backbone.sync. Take a look at this answer: How to override Backbone.sync?
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.