Currently the routing framework I have does not treat /resource and /resource/ the same. So which URL form is more preferred?
/products
or
/products/
Or should I strive to support both?
Currently I am treating it all like this:
/products/ (index)
/products/198
/products/edit/192
Is there a preferred form?
Note that if you use products (no trailing slash), then relative links to a "child" resource must repeat the "parent" resource's path segment. That is, if you use products, then you must write <a href='products/123'>, but if you use products/, then you can write just <a href='123'>. If you're returning lots of such links, that can result in significant overhead. See http://www.aminus.org/rbre/shoji/shoji-draft-02.txt section 3.3.2 for a more detailed discussion.
Wikipedia says one thing, but look at stackoverflow itself - it uses /tags for example. I don't think this makes any differences for a user.
There's no one right way to construct restful urls, but in my own work, I always use urls ending with a slash to return resource collections and resources without an ending slash to reference atomic resources.
I would use /products mainly because of Rails. There endings like .xml and .json specify the response format. In that case /products/.xml wouldn't make much sense.
I use URLs with a trailing slash to indicate indices, or lists of subordinate resources. A URL with no trailing slash generally indicates an individual resource. One of the rationalizations I use for this, is the behavior of the 'ls -l' command on symbolic links to directories. If you do an 'ls -l' on a symbolic link to a directory and include the trailing slash, you get the contents of the directory it points to, but if you so an ls and don't include the slash, you see that it's a symbolic link.
Related
All of these URLs are equivalent:
http://rbutterworth.nfshost.com/Me
http://rbutterworth.nfshost.com/Me/
http://rbutterworth.nfshost.com/Me/.
http://rbutterworth.nfshost.com/Me/index
http://rbutterworth.nfshost.com/Me/index.html
The "rel='canonical'" link allows me to specifiy whichever I want.
Is one of those forms considered "better" or "more standard" than the others?
As a maintainer, I personally prefer the first one, as it allows me the freedom to change "Me" to be "Me.php", or change "index.html" to be "index.shtml", or some other form should I ever need to, without having to define redirects, or to change any existing links to this URL. (This isn't specific to "index"; it could be for any web page.)
I.e. using that simplest form avoids publishing what is only an implementation detail that is best hidden from the users.
Unfortunately, of all the forms, my preferred choice is the only one that web servers don't like; they return "HTTP/1.1 301 Moved Permanently" and add the trailing "/".
For directories, is incurring this redirection penalty worth it?
For non-directories, is there any reason I shouldn't continue omitting the suffix?
Added after receiving the answer:
It's nice to know I'm not the only one that thinks omitting suffixes is a good idea.
And I just realized that my problem with directories goes away if I use "directoryname/index" as the canonical form.
Thanks.
For directories, is incurring this redirection penalty worth it?
No.
"The canonical URL for this resource is a 301 redirect to another URL" doesn't make sense.
For non-directories, is there any reason I shouldn't continue omitting the suffix?
No.
There is a reason to omit the suffix: It leaks information about the technologies used to built the site, and makes it harder to change them (i.e. if you moved away from static HTML files to a PHP based system, then you'd need to redirect all your old URLs … or configure your server to process files with a .html extension as PHP (which is possible, but confusing).
We've just enabled Flexible SSL (CloudFlare) on our website and I was going through swapping all the http://example.com/ to just //example.com/, when I noticed the link to the Font-Awesome css file was like this:
http:////maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css
The http is followed by four slashes, I've seen three (when using local files in the browser) and two is the general standard, but four?
So what does four do? Is it any different to two? And can I swap http:////example.com/ to //example.com/ or should it be ////example.com/?
Is it any different to two?
Well, one is in line with RFC 3986, the other is not. Section 3 clearly states, that the separator between scheme and the authority has to be ://. In case of protocol-relative URLs, the start has to be //. If there is another slash there, it has to be part of an absolute path reference.
The only way for an additional set of slashes there were if those were part of the authority and left unencoded. That could happen if // is the start of:
a user name
a domain name
Neither one seems to be the case here and I am pretty sure that (2) is clashing heavily with the requirements for domain names, while (1) is almost guaranteed to cause interoperability issues. So I assume it's an error by whoever wrote that.
A quick test revealed that firefox is eliminating bogus slashes in the URL while w3m is erroring out.
Is there any protocol or method specifically for listing files (or a list of file meta-data) in a directory?
I saw nothing obvious at http://www.iana.org/assignments/http-methods/http-methods.xhtml . The closest I think I could see was SEARCH which might be used for this purpose but defined no semantics. Are there no standards based on top of HTTP which allow for this?
What you're looking for is PROPFIND (http://greenbytes.de/tech/webdav/rfc4918.html#METHOD_PROPFIND)
On the Microformats spec for RESTful URLs:
GET /people/1
return the first record in HTML format
GET /people/1.html
return the first record in HTML format
and /people returns a list of people
So is /people.html the correct way to return a list of people in HTML format?
If you just refer to the URL path extension, then, yes, that scheme is the recommended behavior for content negotiation:
path without extension is a generic URL (e.g. /people for any accepted format)
path with extension is a specific URL (e.g. /people.json as a content-type-specific URL for the JSON data format)
With such a scheme the server can use content negotiation when the generic URL is requested and respond with a specific representation when a specific URL is requested.
Documents that recommend this scheme are among others:
Cool URIs don't change
Cool URIs for the Semantic Web
Content Negotiation: why it is useful, and how to make it work
You have the right idea. Both /people and /people.html would return HTML-formatted lists of people, and /people.json would return a JSON-formatted list of people.
There should be no confusion about this with regard to applying data-type extensions to "folders" in the URLs. In the list of examples, /people/1 is itself used as a folder for various other queries.
It says that GET /people/1.json should return the first record in JSON format. - Which makes sense.
URIs and how you design them have nothing to do with being RESTful or not.
It is a common practice to do what you ask, since that's how the Apache web server works. Let's say you have foo.txt and foo.html and foo.pdf, and ask to GET /foo with no preference (i.e. no Accept: header). A 300 MULTIPLE CHOICES would be returned with a listing of the three files so the user could pick. Because browsers do such marvelous content negotiation, it's hard to link to an example, but here goes: An example shows what it looks like, except for that the reason you see the page in the first place is the different case of the file name ("XSLT" vs "xslt").
But this Apache behaviour is echoed in conventions and different tools, but really it isn't important. You could have people_html or people?format=html or people.html or sandwiches or 123qweazrfvbnhyrewsxc6yhn8uk as the URI which returns people in HTML format. The client doesn't know any of these URIs up front, it's supposed to learn that from other resources. A human could see the result of All People (HTML format) and understand what happens, while ignoring the strange looking URI.
On a closing note, the microformats URL conventions page is absolutely not a spec for RESTful URLs, it's merely guidance on making URIs that apparently are easy to consume by various HTTP libraries for some reason or another, and has nothing to do with REST at all. The guidelines are all perfectly OK, and following them makes your URIs look sane to other people that happen to glance on the URIs (/sandwiches is admittedly odd). But even the cited AtomPub protocol doesn't require entries to live "within" the collection...
What is the best practice when storing a directory in a file name on a unix system? Should the directory path end in a slash?
Method A
TMP="/tmp/pasteTmp/"
which allows you to do:
cd "$TMP$fileName"
Method B
TMP="/tmp/pasteTmp"
which allows you to do (with an extra slash which seems less clean):
cd "$TMP/$fileName"
but also allows you to do:
cd "$TMP/actualFileName"
Which I think is impossible using the first method.
it doesn't matter. Instead you should always assume the trailing slash is not there when using the path by adding your own. /foo// is equivalent to /foo/ so it works out.
When you refer to a directory in normal usage, you don't include the slash: my home directory is /home/andy, not /home/andy/. If you write scripts that assume the trailing slash is there, sooner or later you'll forget to include it and surprise yourself.
I'm not sure I agree with you that the extra slash "seems less clean". When you're not using variables you expect a slash to separate the directory and file names; when the directory name is stored in a shell variable, I still find it natural to read and write with the slash separating the parts.
When you work on a big monster application with 100's of scripts and lots of libraries and executables, you start to worry more about what causes less pain rather than what "seems less clean". I'd agree that the double slash looks funny but the reality is that Unix doesn't care. I'd rather assume the trailing slash isn't there and know it will still work when I add one myself than hope everyone remembered to include one and then my code breaks when someone else forgets about adding the trailing slash.
Put yourself in a situation where you are in control of whether your code will work. Depending on others to follow a convention leads to headaches and 3am support calls when they inevitably don't.