URIs identify and URLs locate; however, locators are also identifiers, so every URL is also a URI, but there are URIs which are not URLs.
Examples
This is my name, which is an identifier.
It is like a URI, but cannot be a URL, as it tells you nothing about my location or how to contact me.
In this case it also happens to identify at least 5 other people in the USA alone.
- 4914 West Bay Street, Nassau, Bahamas
This is a locator, which is an identifier for that physical location.
It is like both a URL and URI (since all URLs are URIs), and also identifies me indirectly as "resident of..".
In this case it uniquely identifies me, but that would change if I get a roommate.
I say "like" because these examples do not follow the required syntax.
Popular confusion
From Wikipedia:
In computing, a Uniform Resource Locator (URL) is a subset of the Uniform Resource Identifier (URI) that specifies where an identified resource is available and the mechanism for retrieving it. In popular usage and in many technical documents and verbal discussions it is often incorrectly used as a synonym for URI, ... [emphasis mine]
Because of this common confusion, many products and documentation incorrectly use one term instead of the other, assign their own distinction, or use them synonymously.
URNs
My name, Roger Pate, could be like a URN (Uniform Resource Name), except those are much more regulated and intended to be unique across both space and time.
Because I currently share this name with other people, it's not globally unique and would not be appropriate as a URN. However, even if no other family used this name, I'm named after my paternal grandfather, so it still wouldn't be unique across time. And even if that wasn't the case, the possibility of naming my descendants after me make this unsuitable as a URN.
URNs are different from URLs in this rigid uniqueness constraint, even though they both share the syntax of URIs.
For the searching, use querystrings. This is perfectly RESTful:
/cars?color=blue&type=sedan&doors=4
An advantage to regular querystrings is that they are standard and widely understood and that they can be generated from form-get.
Best Answer
The link you added is valid, REST APIs are stateless, so they can't login in the traditional way, you MUST store the client session on the client side. If you use HTTPs you won't need login. If you don't, then your API won't be secure, so using password won't have any protection. I think that's all.
If you want to both stay stateless and send tokens, then you have to sign for example the user id on the server. So by the next request you can send both the user id and the signature instead of the email and password. This way the server will know that you have been logged in earlier to the account the user id belongs to. I don't recommend you to use the URI for sending sensitive data. It is better to use the request body with POST. The URI structure depends on your taste, I would use something like this:
Be aware that you have to send every variables you signed, so, the id, the expiration time (added by the server), probably the ip address, a random number, etc... You MUST not store anything on the server (including the token), otherwise the communication will be stateful.
I am not a security expert, but I think this solution does not make sense in most of the cases, so you need to justify somehow, why your API needs it. It is used for example for signing each request coming from 3rd party clients. If you cannot justify it, I recommend you to use the default approach, which is using HTTPS, logging in on the client side and sending HTTP Authorization header with email and password by every request.