I am designing my namespace such that the id i am storing in the DB is
id -> "e:t:222"
where "e" represents the Event class, "t" represents the type
i am also expecting to use this id in my urls
url -> /events/t:222
Is there anything wrong with doing this?
Is there anything wrong with doing this?
Yes: The colon is a reserved character in URLs that has a special meaning, namely specifying the server port, in a URL.
Using it in other places in the URL is a bad idea.
You would need to URLEncode the colon in order to use it.
There is nothing wrong with doing this, you'll simply need to encode the URL properly. Most libraries with do this automatically for you.
In general though, if you care about your data you shouldn't let the application drive the data or database design. Exceptions to this are application centric databases that have no life outside of a single application nor do you expect to use the data anywhere else. In this case, you may want to stick with schemas and idioms that work best with your application.
Related
We can use
'PATCH /companies/:id' : 'CompanyController.find'
to update data.
One suggested me that I can use the alternative way:
'PATCH /companies/find?key=Value'
But I do not know what it works. Please explain me why we prefer ? mark than : mark in search path.
You can use either or. The biggest reason most people chose one or the other is just how they want to present the URL to the user.
Using a path variable (:) can symbolize you're accessing a defined resource, like a user ID, where as an argument (?) can symbolize you're are dynamically changing/searching something within a defined resource, like a token or search term.
From what I can tell that's the general practice I see:
example.com/user/:username
versus
example.com/user/?search="foo"
http://en.wikipedia.org/wiki/URL
If we are firing GET request, ? symbol is used to let the server know the url parameter variables starts from there. And this is commonly used. I didn't used : symbol instead of ?
You are probably messing the things up:
According to your example, :id indicates a variable that must me replaced by an actual value in some frameworks such as Express. See the documentation for details.
And ? indicates the beginning of the query string component according to the RFC 3986.
It's a rule to design rest api
you can find 'how to design a rest api'
Assuming below code is Sails.js
'PATCH /companies/:id' : 'CompanyController.find'
It will makes REST API that be mapped onto 'CompanyController.find' by using PathParam. Like this
www.example.com/companies/100
Second one will makes REST API by using QueryParam.
It also be mapped onto 'CompanyController.find'
/companies/find?key=Value
But the API format is different. Like this
www.example.com/companies/find?key=100
PathParam or QueryParam is fine to make REST API.
If the Key is primary for company entity,
I think PathParam is more proper than QueryParam.
I have some easy to read URLs for finding data that belongs to a collection of record IDs that are using a comma as a delimiter.
Example:
http://www.example.com/find:1%2C2%2C3%2C4%2C5
I want to know if I change the delimiter from a comma to a period. Since periods are not a special character in a URL. That means it won't have to be encoded.
Example:
http://www.example.com/find:1.2.3.4.5
Are there any browsers (Firefox, Chrome, IE, etc) that will have a problem with that URL?
There are some related questions here on SO, but none that specific say it's a good or bad practice.
To me, that looks like a resource with an odd query string format.
If I understand correctly this would be equal to something like:
http://www.example.com/find?id=1&id=2&id=3&id=4&id=5
Since your filter is acting like a multi-select (IDs instead of search fields), that would be my guess at a standard equivalent.
Browsers should not have any issues with it, as long as the application's route mechanism handles it properly. And as long as you are not building that query-like thing with an HTML form (in which case you would need JS or some rewrites, ew!).
May I ask why not use a more standard URL and querystring? Perhaps something that includes element class (/reports/search?name=...), just to know what is being queried by find. Just curious, I knows sometimes standards don't apply.
I have developed a ASP.NET MVC application. I have a conroller with the name EmployeeController and it got a method called GetEmployeeByName. GetEmployeeByName() takes a name of type string as parameter.
So When I send a request like this, i get the data back :
someDomain:9999/Employee/GetEmployeeByName/Roger Federer
But if the name contains an '&' (you & me), I get a '400 Bad Request' as response from server.
someDomain:9999/Employee/GetEmployeeByName/you%20&%20me
Even if i encode it dont get a reposne back
someDomain:9999/Employee/GetEmployeeByName/you%20&%20me
What is the right way to encode such (data with special character) data?
What is the right way to encode such (data with special character) data?
The right way is to use a query string parameter and not be putting those things as part of the uri portion. Read the following blog post from Scott Hansleman. I will only quote hos conclusion:
After ALL this effort to get crazy stuff in the Request Path, it's
worth mentioning that simply keeping the values as a part of the Query
String (remember WAY back at the beginning of this post?) is easier,
cleaner, more flexible, and more secure.
As you can see in the blog post there are some hacky ways to make it work and circumvent IIS handling but it simply is not something that I would recommend you venturing into. Just put this name in the query string.
So, the problem seems simple at the beginning but is not. Using Mongo and Node.js.
Problem: I have a URL. I need to match that URL with all the URLs I have in my database. Remember, there is no rule that the URL I'm on always have "category" infront or things like that. And please don't take "cases" into consideration.
I have no clue of the name of parameters, or anything else.
Let's assume the URL is smth like example.com/category/product_name.html?session_id=2423412fd
In the database I only have example.com/product_name.html
The URL is smth like example.com/index.php?productid=6&category=3&utm_campaign=google&utm_source=click
In the database I only have example.com/index.php?productid=6
The URL is smth like example.com/product_name.html
In the database I only have example.com/category/subcategory/product.html
I think I made my point. What I'm looking is a solution that matches URL in any cases (they are more than these). It can be an external services, class or something complex.
But I need it to work, and to work very fast because is doing this on every page refresh.
Thank you!
I would use this function to separate the strings http://php.net/manual/en/function.parse-url.php
Then take parts of the path name which you want to match from the URL and query your database URL's looking for matches.
To follow on from Anagio's answer, the URL
example.com/index.php?productid=6&category=3&utm_campaign=google&utm_source=click
could be saved as a Mongo object like:
{
url: "example.com/index.php?productid=6&category=3&utm_campaign=google&utm_source=click",
indexes: [
"example.com",
"index.php",
"productid=6",
"category=3",
"utm_campaign=google",
"utm_source=click"
]
}
You could then split up any new URL using the same algorithm, then do a map/reduce on the indexes field for scoring and then take the highest score as the best "fuzzy match"
I have a Rails app that needs to expose values from a database as a web service - since I'm using Rails 2.x, I'm going with REST (or at least try). Assuming my resource is Bananas, for which I want to expose several sub-characteristics, consider this:
- /banana -> give a summary of the first 10 bananas, in full (all characteristics)
- /banana/?name=<name> -> give all characteristics for banana named <name>
- /banana/?number=<number> -> give all characteristics for banana number <number>
- /banana/?name=<name>/peel -> give peel data for banana named <name>
- /banana/?number=<number>/length -> give length data for banana number <number>
I don't want to search for ID, only name or number. And I have about 7 sub-characteristics to expose. Is this RESTful?
Thanks for any feedback!
What Wahnfrieden is talking about is something called Hypermedia as the Engine of Application State (HATEOAS) - a central constraint of REST as defined by Fielding.
In a nutshell, REST application clients never construct URIs themselves. Instead, they follow URIs provided by the application. So, URI templates such as the ones you're asking about are irrelevent at best. You can make them conform to a system if you'd like, but REST says nothing about how your URIs need to look. You could, if you wanted to, arrange it so that every resource in your system was available from http://example.com/{hash}.
Publishing URI templates, such as the ones you're talking about in your question, introduces tight coupling between your application and clients - something REST is trying to prevent.
The problem with understanding hypermedia-driven applications is that almost nobody implements or documents their "RESTful" systems this way.
It might help to think about the interaction between a human and server via a browser. The human only knows about content and links that the server provides through the browser. This is how a RESTful system should be built. If your resources aren't exposing links, they're probably not RESTful.
The advantage is that if you want to change your URI system, for example, to expose the Banana "Peel" attribute through a query parameter instead of a nested URL, you can do it anytime you'd like and no client code needs to be changed because they're not constructing links for themselves.
For an example of a system that embraces the hypertext-driven constraint in REST, check out the Sun Cloud API.
I would use these:
/banana
/banana/blah
/banana/123
/banana/blah/peel (and /banana/123/peel)
/banana/blah/length (and /banana/123/length)
First, common practice for ReSTful URIs is /object_name/id/verb, with some of those absent (but in that order). Of course, this is neither required nor expected.
If all your names aren't made of digits, you don't have to explicitly have name in /banana/name/blah. In fact, if anything, it would be better to have id as identifier: /banana/id/123/peel. Hope this helps.
Parameters should only be used for form submission.
Also, URI naming schemas is totally unrelated to REST. The point of REST is to make related resources discoverable via hypertext, not out-of-band conventions, and only from a limit number of entry points. So your /bananas/ entry point might provide the summary info for 10 bananas, but it must also provide the URI for each of those bananas' details resources, as well as the URI to get the summary for the next 10 bananas. Anything else is just RPC.
It is good practice in REST to not use query parameters because query parameters don´t belong to a URL and in REST all resources should be addressable through a URL.
In your example /banana/?name=name should be /banana/name because you are referring a concrete resource.
Even I think /banana/?number=number/length is not good REST style, because you are selecting an attribute through a URL when you should retrieve the whole state with /banana/name . A difference could be /customers/1024/address to get the Customer 1024 address record.
HTH.
A more opt form for the route in url having query string is the plural form, as it is possible that multiple items are returned in the result. In this case, bananas, like bananas?color=yellow, sounds more appropriate.
On the other hand, the singular form banana, like banana/123, is good when fetching a specific resource's representation when its identifier is known and query string is not required.