How can i get the 'id' when i want to match url like '/index?id=xxx' in koa-router? most articles on the web usually use url lick '/index/:id',but the back-end interfaces are not the case.
It does work the same on a back-end API, when you make a GET request to a web server it parses the query-string and uses the values to give you the intended response.
When handling a GET request using koa-router you can specify the query string, such as '/index/:id', and to consume the value in your code you would simply do
var id = ctx.request.query.id;
Related
I need to load test one Python api in below URL format:
//IP:PORT/Sub_Part/?where={"KEY1":"VALUE1","KEY2":"VALUE2","KEY3":"VALUE3"}
I tried to pass the key value pair through csv as well as directly in http request but getting error message.
java.net.URISyntaxException: Illegal character in query at index 47:
http://IP:PORT/Sub_Part/?where={"KEY1":"VALUE1","KEY2":"VALUE2","KEY3":"VALUE3"}
Here key and value are dummy data I have placed here for easy understanding.
Please help me with correct syntax for this URL.
Thanks in advance for all your help.
In REST APIs, JSON objects are typically sent (POST) or returned in the body of the request. They are not typically encoded as part of the URL.
For a GET request, you can either pass the information as segments in the url or as querystring parameters.
For more details refer here, How to send a GET request with a "/" in the query
As per HTML URL Encoding Reference:
URLs can only be sent over the Internet using the ASCII character-set.
so you need to define the request in JMeter's HTTP Request sampler as follows:
Pay attention to URL Encode? checkbox, it has to be ticked otherwise the parameter will be sent "as is"
Another option is using __urlencode() function like:
http://IP:PORT/Sub_Part/?where=${__urlencode({"KEY1":"VALUE1"\,"KEY2":"VALUE2"\,"KEY3":"VALUE3"})}
which will generate an encoded sequence which you could use in the URL path:
%7B%22KEY1%22%3A%22VALUE1%22%2C%22KEY2%22%3A%22VALUE2%22%2C%22KEY3%22%3A%22VALUE3%22%7D
as you can see, all non-ASCII characters where removed.
Check out Apache JMeter Functions - An Introduction to learn more about JMeter Functions concept.
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.
I am building a results filtering page using AJAX requests. I would like to reflect the filters in the URL. For example: for price_from I want to add ?price_from=VAL to the URL.
I have a backend that is capable of rendering the page with URL parameters.
After some googling I would a Backbone.router solution which has a hash fallback for the IE that does not support HTML5 history API.
I have a problem with setting a good philosophy of routes. I have a set of filtering parameters (price_from, price_to, color, ...) and I would like to attach each parameter to one route.
Is that possible to chain the routes to match for example: ?price_from=0&price_to=1&color=red? (the item order can change)
It means: call all the routes at the same time and keep the ie backwards compatibility?
Your best bet would be to have a query portion of the URL rather than using GET parameters to denote the search criteria. For example:
Push state: /search/query/price_from=0&price_to=1&color=red
Hash based: #search/query/price_from=0&price_to=1&color=red
Your backend would of course need to change a bit to be able to parse the new URL structure.
When I use HTTPService.send(paramter) as a POST request, the web server does not appear to see variable "parameter" if it is a string. The server sees the parameter if it's an Object, but I'm looking to use something like httpservice.send(JSON.encode(object)); Is this possible?
Why not use the actual request objects.
in your service define request objects and post them or send them as get if you please.
Sample code here: http://pastebin.com/ft7QW2vg
Then just call .send on the service.
on the server you can simlpy process if with request.form (Asp)
Failing which why not append it to the url with a binding expression. (you would need to encode it since you would be more or less faking a url or a get behaviour).
I have a RESTful URL that requires either the offset or the prefix request parameter (but not both).
GET /users?offset=0&count=20
GET /users?prefix=J&count=20
What's the best way to enforce this rule? Spring has the #RequestParam annotation with the 'required' property for optional parameters, but I want to enforce an "either-or" rule on these two parameters. I know I could do it in the code, but is there another way to do it?
Also, what's the proper way to handle "impractical" requests? Say I have 100 million users; the following request, although properly RESTful, is not something I want to support:
GET /users <-- Gets all 100 million users, crashes server and browser!
What should I send back?
You can create two methods and choose one of them with #RequestMapping's params attribute:
#RequestMapping(..., params = {"prefix", "!offset"})
public String usersWithPrefix(#RequestParam("prefix") ...) { ... }
#RequestMapping(..., params = {"offset", "!prefix"})
public String usersWithOffset(#RequestParam("offset") ...) { ... }
what's the proper way to handle "impractical" requests?
The lesser-practiced principles of REST include the requirement that resources be "discoverable". If you are asked for a complete list of 800 million users and you don't want to provide it, you might instead consider serving a page that describes in some way how to filter the collection: for example, an XForms document or HTML containing a FORM element with fields for offset/prefix/count, or a URI template with the appropriate parameters
Or you could just send a "413 Entity too large" error - edit: no you can't. Sorry, I misread the description of whath this code is for
If you decide to go down the route of just sending the first page, I think I would send it as an HTTP redirect to /users?offset=0&count=20 so that the client has a better idea they've not got the full collection (and if your response contains a link to access subsequent pages, even better)