In websites, data can be sent using an HTML form to POST /createUser with a payload in the body, and expect a redirect to some page (for example, to a newly created user) in response. Or you can send the same request using an AJAX request (fetch, axios) and expect a JSON response (in which, for example, the same link to a new user can be a field {”redirectTo”: “/createUser”} along with another response payload).
How to distinguish these requests in the controller from the MVC pattern in order to respond with what the client expects? I see these options:
Create different URLs - one for a request with a redirect, the other with a response in JSON. But here the problem is that they have the same logic, only the view-representation differs.
Common URL, but an additional field in the body or header, in which the client himself will explicitly indicate what kind of response he expects.
A common URL, but the server itself determines from the request headers (for example, Content-Type) where the request was made from and what the client expects. But aren't there some edge scenarios where the server might guess wrong?
Related
There is a way to config the Twilio webhooks in the conversation product to send a post request to an endpoint and in the body send the information instead in the params?
You would pass a payload of the JSON you want to send in your post body and then pass in a header called x-www-form-urlencoded which tells Twilio that you want the parameters to be sent in the body as form data. I'm not sure if it's limited to only a few parameters or not but I know that it works with \"To\" and \"From\" (as they need to be URL encoded). It would definitely work with MessageSid.
You could also use the \"Bulk\" post body format, which is just JSON. This would allow you to pass more parameters since it's just JSON. (You don't need to url encode them if you do this, so no need to have x-www-form-urlencoded header.)
{
\"To\": \"+15551235555\",
\"From\": \"+15551234567\",
\"Body\": \"A text message\",
...: ...
}
You should be able to send the information you want, along with the headers, from your endpoint and have it pass through Twilio.
Looks like this:
curl -X POST https://api.twilio.com/2010-04-01/Accounts/{AccountSid}/Messages -d 'From=%2B15551234567&To=%2B15551235555&Body=Test' -u '{AccountSid}:{AuthToken}'
You can pass any JSON you want as a body using this option but make sure you've set your \"Content-Type\" header to \"application/x-www-form-urlencoded\". This is pretty straightforward and makes it easy to pass in whatever parameters you want.
This isn't limited to text messages! This is exactly how I push data back into a Conversation or Action resource too so it'll work for things like card pushes too! You can use this to programmatically create a response that Twilio will process and then act on in your Conversation or Action instance.
And yeah … if you're going to support a webhook that takes form data then I would suggest adding some basic security checks since anyone could just post random stuff as form data if they wanted and get access to your endpoint. I'd recommend checking the Request Method as well to make sure it's POST.
If you're worried about someone passing in a bad value then you can just check the request body against some regex. I'd recommend checking the Twilio-To and Twilio-From params as well. You could also use the request header too, which is passed along with all webhooks:
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: POST');
header('Access-Control-Allow-Headers: xxx');
So these three methods are in the Laravel docs for testing if the request is for JSON.
I basically want to return JSON for any request that is requesting JSON or AJAX.
Request::ajax()
Request::isJson()
Request::wantsJson()
Can I use any of these? Do they overlap?
Not all AJAX requests expect a JSON response, so utilizing request()->ajax() is useful where you want to determine if the request was an XmlHttpRequest or not, but the response doesn't care about JSON or not.
Not all requests that contain JSON expect a JSON response. so if you don't care about whether or not the response wants JSON back, but want to determine if JSON was sent in the request, then isJson() is useful for you.
Not all requests that want JSON responses are AJAX driven, so wantsJson is useful in the case where you want to return JSON data, but you don't care how the request came to your server.
Based on these descriptions, make assertions and choose the proper functions.
You can use Request::expectsJson(). It returns true if request is ajax or wants json.
request()->ajax() is usefull if you want to check if request is only Ajax
Request::wantsJson() is usefull if you want to check if request is only Json
Request::expectsJson() is usefull if you want to check if request is either Ajax or Wants Json
In Laravel we use routes to deal with HTTP requests from the browser.
We can route a request to a controller, do some logic and then return a response.
Now, we can send in variables encapsulated with braces {} and the response can be anything, so it seems to me that routing through a controller means that the the properties of the different request methods (POST, GET, PUT etc.) are lost.
For example I could send a POST request with URI example/{id} then put in my routes.php file
Route::post('example/{id}','SomeController#SomeAction');
Then I could do something in my controller with the variable $id and send a response.
On the other hand I could send a GET request with URI example/{id} and alter my route to
Route::get('example/{id}','SomeController#SomeAction');
The controller would give the same response.
So, am I right in thinking it does not really matter what request method is used?
Two parts of your question I can identify on a second read-through:
Request methods are not lost. You have access to them with $request->getMethod(). So a GET request will return GET. You also have the method isMethod('GET') available to you, which you could use to get a truthy value which would enable you to return a different kind of response depending on the request type.
With regards to the way you set up your URL, what HTTP verb you use does matter if you're creating a REST-ful web service.
I won't explain away what a REST-ful web service is (you can look it up), here is a couple of points from your example:
If you're getting some data, you ought to be doing a GET request. It is the verb to represent a read from a resource. If you had to send a lot of data - and your intention is to add data, you ought to POST it instead.
The URI should be meaningful in a way that best describes the resource you are manipulating.
Together with the HTTP verb, you can infer the implied action. So if you are POSTing to example/1, I might infer that (and this is a digression, actually) that you are attempting to update record 1 from an example resource. In reality, you would perhaps use the PUT verb (which handles update).
Behind the scenes, Laravel uses a POST request due to browser limitations but treats it as a PUT request server-side.
Of course request type does matter. When you want to hide some request data against user and dont show it in url for example:
?username="Admin"&nick="admin1" then u will use POST otherwise you can use GET. When you want get some data u will use GET but when you want to send some data then you should use POST instead.
In my Cappuccino frontend I'm using Ratatosk to make queries to a RESTful JSON-based API.
When I create a new resource with
[myNewResource ensureCreated];
my backend returns the status code 201 and a Location header with the URI of the newly created resource. The response body is empty. As far as I know, that's the way a REST API should react to successful POST requests.
But upon receiving the response, Ratatosk calls
- (void)connection:(CPURLConnection)aConnection didReceiveData:(CPString)data
(in WLRemoteLink.j) and tries to decode the response body. This throws an error because the response body is empty. As a consequence, the request is repeated infinitely.
How should I go about this? Am I supposed to return the whole resource in the response body?
EDIT:
Returning the ID in the response solved the problem, like
{"id":1}
Ratatosk expects the status code 204 (no content) if the response is to be empty. Otherwise it expects the full representation of the resource which was just created (which it uses to populate server side dynamic properties locally like created_at).
In my sinatra app i have a form which is used to submit data via a POST request to a url.The url also accepts json sent in a POST request.
Is there any way to determine in the handler if json data was received in the post or the data submitted was sent from the form ?
Thank You
When you send data via a Post request you will have data in your params Hash. So if there is a key there is a value, even if it's empty. So you can check for example via params[:json] if you have received something via json (assuming you call that parameter :json). The same goes for data. But then I'm not entirely sure if that's what you're asking for. Either way all data you get is handled via the params variable.
Assuming that JSON is sent via XHR call, you can make use of request.xhr? to check if the request is xhr.