Is it possible to set a filter for request for certain type of method like GET, POST, OPTIONS?
I am using Map Local or Map Remote and I am interested in mapping only GET request. Unfortunately, my browser also sends request with method OPTIONS that have exactly same address.
Related
I write an API for report fetching with detailed filters, such as filters for recordIds, userIds, tagIds, basically multiple different id lists are part of the filter.
So far I coded these fetches as POST requests with id lists in body but I got curious if it is possible to handle these filters as a GET request instead?
What I searched so far yielded that, it doesn't seem possible since there is multiple List based filters and request is likely too big to be a GET but still, I'm curious if there is possible work arounds?
In my opinion, this is according to your requirement.
If you are using post, you could post a complex object inside the body and this request will be more security than the get method.
If you wan to use get method, you could put all the parameter inside the url. Each url will contains the limit and build the complex object in the url is not recommended. If this also match your production environment, you could modify the codes to use get method.
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.
Why do we have different methods for HTTP request. GET can not send data(body) and can only request something only through URL params. Put is like changing a field value on the server and Post performs an operation everytime we execute it (concept of Idempotence).
Why can't there be one method or no method at all ?
Why can't there be just a simple HTTP request where we can send data if we want. Now it depends on server logic how it wants to process that request based on the request content (data / body). If the server wants to just execute it like a get request & return something or perform an operation like a POST request & return something. It would have been more simpler.
Why can't there be just a simple HTTP request where we can send data if we want
Because that's not how HTTP works. Each HTTP request has a required request method.
REST leverages this by reusing the semantics of the methods.
Why can't there be one method or no method at all ? Why can't there be just a simple HTTP request where we can send data if we want.
Because describing the semantics of the messages in a consistent way allows generic components to participate in a meaningful way.
For instance, the semantics of a given request are constrained by the common method properties; if the metadata of the message describes itself as idempotent, then generic participants know that, in the event that a response is lost, they can simply repeat the message.
Likewise, if a message is known to be safe, then each of the components know that the message can be dispatched speculatively -- allowing caches to prefetch representations that you may need, communicating to spiders that the content is safe for retrieval and so on.
The HTTP methods support finer grains of distinction; GET vs HEAD, PUT vs DELETE, POST vs PATCH. And of course there are extensions that support other semantics as well.
From the perspective of REST, it doesn't have to be a method per se, so long as the semantics are expressed in such a way that generic components can act on it. HTTP happens to have used methods.
The request method token is the primary source of request semantics; it indicates the purpose for which the client has made this request and what is expected by the client as a successful result.
You are absolutely right that no method at all would be much simpler. But it would also be a lot less powerful: you lose the ability to leverage generic components (like web browsers, caching proxies). The metadata constraints are what make the web possible.
It's all about the semantics of the request. From the RFC 7231:
The request method token is the primary source of request semantics;
it indicates the purpose for which the client has made this request
and what is expected by the client as a successful result.
Here's a brief description of some HTTP methods defined in the RFC 7231 (click the links to check the full method definition):
GET: Transfer a current representation of the target resource.
HEAD: Same as GET, but only transfer the status line and header section.
POST: Perform resource-specific processing on the request payload.
PUT: Replace all current representations of the target resource with the request payload.
DELETE: Remove all current representations of the target resource
I am trying to stub out a request locally with a response saved within a local file. This is working fine however I need to get to ignore an initial request of the same URL but with a Method type of Options.
The problem is, the local mapping is being mapped to this request instead of the Intended GET request which leads to an error. Is There away way I can specify something extra so the initial options request which comes back is ignored.
Example image
Hope this clear enough
Thanks.
It's a limitation of Charles, that doesn't allow you to specify the matching HTTP Method.
I suggest using other tools like Proxyman, that you can define which Method you need for the Map Local Tool. You can map entire Response HTTP Message (Includes Header and Status Code as well)
Given a one page app that uses push state and RESTful backend, we can imagine accessing the listing of a resource at /resourceName (i.e. /users). So /users would create a formated list of users
Now the problem is that this resource JSON or XML feed should also be mapped to /resourceName, so if boot form my application entry point at / then all is good, when navigating to /users the JS router can trigger a Ajax call that get the JSON data. Now the problem is if the URL is pointing directly at /users then i will land on a JSON feed instead of the actual listing. I could route all call to a main entry point and then let the JS router do the work though if i do so the AJAX call to fetch JSON wil brake.
I remember a while ago people adding .json to their json request, or even a GET parameter ?format=json and then having the controller taking different actions. I find that somewhat hacky.. Are there any other ways to go about this?
For that matter i am using laravel4 backend and backboneJS
I think the .json on the end of the request is the best approach. the other approach could be to create a separate endpoint endpoint for api request api.mydomain.com vs www.mydomain.com
What method you use to get a different response depends on how you'd like to go about it. Since you're asking about an opinionated topic (There is no one right answer), here's some options you can explore.
First, here's a good read from Apigee on API design, which covers what I'll write about here. See page 20 on "Support multiple formats"
The Rails way: Append a .json, .xml or other extension at the end of your request and handle that code within Laravel (You may want to use the "before" filter to check the request or Laravel's excellent route parameters, which allow the use of regex to define the route).
You can check the "accept" header in the request and set that header in your ajax calls to "application/json" instead of the default "application/html" to inform your application which format to use in its response. Again, the before or after filters may come in handy to check the request and define the response as appropriate
Create a query string `?format=json" or similar. Same comments as in point 1.
Laravel doesn't have built-in methods to change the response for you. You can, however, fairly easily detect what's being asked and choose which format to return in. It does take some thinking about how you want to accomplish that, however.
Some options off the top of my head:
Use the "before" or "after" filter to check what the request "wants" for a format, and do some transformations on the response to make that work
Extend the request and response class to "automate" this (request class to detect format, response class to transform the response to the correct format)
Hope that helps
It's valid to say which representation do you want. E.g. JSON, XML or binary, depends on what you want and which serializers have you developed.
You framework should support either setting of default representation or if you provide some mapping URL -> method you should be able to say which representation you are going to return - also either by default or taken within some object which represents your request.
I ended up using different endpoints as suggested by #Aaron Saunders. In laravel 4 this is dumb easy to implement using group routes:
app.php:
'domain' => 'whatever.dev',
routes.php:
define('APP_DOMAIN', 'app.' . Config::get('app.domain'));
define('API_DOMAIN', 'api.' . Config::get('app.domain'));
Route::group(array('domain' => API_DOMAIN), function()
{
// API ROUTES
});
Route::group(array('domain' => APP_DOMAIN), function()
{
// VIEW ROUTES
});
Beautiful!