What's the difference between using : and ? in a URL? For example /products/:id and /products?id=1? I am trying to get the values from the URL like this Product.findById (req.params.id) but I was wondering which one is most suitable. I know using : do I have to use req.params and ? req.query but I don't understand the difference between them, are they the same?
in my point of view, it is totally different if you are using RESTFUL API pattern
/products/:id called path parameters
The path parameters determine the resource you’re requesting for. Think of it like an automatic answering machine that asks you to press 1 for service, press 2 for another service, 3 for yet another service and so on.
Path parameters are part of the endpoint itself and are not optional
but query parameters
Technically, query parameters are not part of the REST architecture, and they used to help you completely understand how to read and use API’s Query parameters give you the option to modify your request with key-value pairs.
Having your parameters in the query is conceptually optional to the router, query parameters are more of properties and descriptions of the request itself, like when saying GET /users?sort=asc, in this case, the sort attribute was more of a description to the request and the request could complete the fetch without it, that might not always be the case, but a query parameter still describes its request even if it was mandatory.
On the other hand, URL parameters are part of the request itself, the URL without the parameter doesn't make sense, like GET /users/:userID, in this case, not supplying userID will supply unexpected data (A list of users for example) if it didn't break the router completely. URL parameters play part in defining the request rather than just describing it, and they can't be optional.
Related
Routes in Express:
/search/:company-name
/search/:category-name
I can see that first one is fired for both requests so they are same, but is there a way to solve this without involving for example:
/search/company/:company-name
/search/category/:category-name
Yes, they are the same.
The router just see a route that starts with search/ and ends with a wildcard. The only thing that change is the name you give to that wildcard, which doesn't matter for the router, it's still the same URL.
You can solve this by either changing the route, or you can parse the route argument (the wildcard) and do something different depending on its value.
You could use a query instead of a param.
Your urls would be:
/search?company=company-name
/search?category=category-name
Your route is /search and you use req.query instead of req.params.
It's either that,
or your solution of changing the route,
or somehow parsing the parameter to decide whether it's a company or a category
or changing your route to a post and using key-value pairs in the post body
It seems that /patient/123 and /patient?id=123 will both work fine at the backend of my application.
I could do req.param.id and do req.query.id as well.
But I'm getting confused on when to use then. What are the cases that you should use params and what are the cases that you should use query. Because in the answer here, j_mcnally only mentioned that they're interchangeable.
Url params and url path are somewhat interchangeable. People usually use url path for describing restful resources...
So what are the possible pros and cons of using them.
The query string is usually modifiers to the resource you're running, while the path should give just enough info to let your back-end indentify the data you're requesting.
/patients/123 - patients in this case would be the namespace, and 123 would be the identifier. You can also extend this with:
/patients/123/profile where profile would be an identifier for a pre-defined collection of data.
Query string usually offers fine-grained control over what and how your resource presents data, for example:
/patients/123?fields=firstname,lastname,age - This is pretty self-explanatory, but basically the query string in this case modifies what data is returned.
/patients?orderby=age&order=desc&fields=firstname,lastname&limit=25 - This query string modifies both how and what data is returned, and that's the purpose of the query string in RESTful API's.
I want to make HTTP requests with some known cookie key-value pairs (e.g k1=v1; k2=v2; ...) using wreq, but can't find a convenient way of creating them.
Because Cookie has many fields, I'd prefer a smart constructor than having to fill all fields on my own.
By browsing documents, I find generateCookie to be the most promosing one (and that's also the only one I've found that returns a Cookie): I can create SetCookie and all I need are just key value pairs. But we don't have a Request to feed it as the second argument. Using http-client alone, one can do parseUrl to create one. But in wreq I feel the author want to hide Request from user and I can't find a function that gives us direct access to it.
So my question is: are there better ways to create cookies in wreq than using Cookie constructor?
I'd probably fork the generateCookie implementation, as it looks like the Request argument is used only to validate the fields.
http://hackage.haskell.org/package/http-client-0.4.26.2/docs/src/Network-HTTP-Client-Cookies.html#generateCookie, except for default cookie path, as SetCookie has Maybe path.
When I have this URI and pass in the PlayerCode: 12345, everything is good.
https://abc.com/teams/players/12345
But when I have a list of 9000 player codes how do I pass the specific list of order code list for a GET operation?
While this question -asked before,here - suggests "an" answer I am not sure if it is "the" answer. I am not sure if I should be going for something like :
https://abc.com/teams/players/?PlayerCodes=12345,23456,34567,45678....
and then have custom model binders to cater to the above.
Does passing in 9000 comma separated values in a URI make sense?
What would be the optimal solution for this scenario?
unfortunately, when you get into the realm of big numbers like 9000, query string parameters will not be sufficient. I assume you are running your solution in IIS or IIS express, both of which have character limits on the query string of somewhere around 2048. In this scenario you can either choose to do an HTTP POST and post a body of the playerId's for the players you need to retrieve, or you could rework your architecture a bit and break your GET calls up into acceptable sizes.
I am trying to find a list of relevant types to a certain string from Freebase, lets say for example i enter Jordan, then i will have a list with types country, person, athlete .. etc.
I have found several ways for the query, for example:
First Query
trying to get the JSON fails, using:
$.getJSON('http://api.freebase.com/api/service/search?query=jordan',function (data) {
console.log(data);
});
There is another query that gives me better result, as i only get the types here but i also cannot get the JSON file from it.
Will appreciate any help.
Your problem has probably less to do with freebase and more to do the fact that you can't do cross domain http requests. You are requesting data from api.freebase.com but you are probably hosting this page in another domain.
You can use the JSONP mechanism to circumvent that restriction, here is some documentation:
http://api.jquery.com/jQuery.getJSON/
Read the section JSONP.
Another couple of points:
Are you trying to search for all entities that somehow match the word "jordan" or are you looking for exactly all the entities that are named "jordan" ? Your best bet is to use the /search API instead of /mqlread which is for structured database queries.
You are also using the legacy API that is deprecated. Here is some docs on the new API:
http://wiki.freebase.com/wiki/API
Here's how your request will look (note that you 'll need an API key for production):
https://www.googleapis.com/freebase/v1/search?query=jordan&mql_output=[{%22name%22%20:%20null,%22type%22:[]}]