Dan Rigsby - Coding Up Style

I have heard many people say that the definition of REST is to just put everything in the URL.  This isn’t true.  One of the tenants of REST is to “embrace” the URL and use it as much as possible, but moving information to POST data is just as important and often necessary.  I can understand how this can be misunderstood.  Most REST interfaces do take in all values in into the URL to make it easier to navigate the data.  Having to build a POST package can be tedious at times.  So, what if you do want to send larger data to the service?  When should you decide to move away from a pure URL approach and start using POST data in the header?

Browser and WebServer Limits: http://www.boutell.com/newfaq/misc/urllength.html

• Internet Explorer: 2,083 characters, with no more than 2,048 characters in the path portion of the URL
• Firefox: 65,536 characters show up, but longer URLs do still work even up past 100,000
• Safari: > 80,000 characters
• Opera: > 190,000 characters
• IIS: 16,384 characters, but is configurable
• Apache: 4,000 characters

Different things can happen when you go beyond these URL limits depending on the browser and web servers. It could be a “413 (Entity Too Large)” error, “414 (Request-URI Too Long)” error, the URL could be truncated, or it may just work.  However since different things can happen and your service could be consumed by any source, you have to assume the worst could happen.

By looking at just these numbers, it seems you would be pretty safe with a URL that gets up to 2,000 characters.  However, lets look at the W3C standards on this.  The HTTP specification doesn’t really set a size for the length of a URL, but it does recommend being cautious when going above 255. According to Hypertext Transfer Protocol - HTTP/1.1 section 3.2:

Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

So for the sake of a REST interface you should avoid setting up an interface where there is any possibility of a URL getting beyond 255.  If you are using a GET verb to request a resource via the URL you should be pretty safe.  However POSTing or PUTing an insert or update via a URL may not be the way to go unless the data size is very small.

The most important thing is to keep your interfaces consistent.  You don’t want one operation that allows an insert via the URL and another through POST data.  This just makes things confusing and less discoverable.  Especially since REST has no way to publish metadata about the operations.   You could follow standards such as these:

In general this follows “High REST” which is the more pure REST.  This dictates that the HTTP Verbs define the methods to act on the resource.

Ultimately it’s up to you how you implement the REST interface, but stay consistent, be careful about URL limits, and try to follow industry standards.