Should a REST API be case sensitive or non case sensitive?

Question

At work we got a problem with case sensitive REST api which ignores wrongly spelled parameters without returning any error. In my opinion this is bad. Then it comes the gene

Answer 1

At work we got a problem with case sensitive REST api which ignores wrongly spelled parameters without returning any error. In my opinion this is bad.

Then don't do that. Validate your parameters. Enforce "missing" parameters. Don't send bad requests in the first place. Conforming to an API, especially at such a level of spelling the parameters correctly, is not a gross burden.

Should a REST API be case sensitive or non case sensitive?

As has been mentioned, URLs are case sensitive, so there really isn't much room for negotiation here. Up/downshifting urls/parameters confuses everybody and it makes your URLs not unique. Again, it's not an extreme demand to expect implementors to use the proper URLs. These URLs are (most likely) not typed in by random people, they're implemented code or web pages. Finally, this only impacts the entry point URLs. The rest of the URLs should be direct copies lifted from the payloads because you're following HATEOAS. Those URLs shouldn't be messed with at all, and simply parroted back.

Simply, if case sensitivity is an issue, you're doing it wrong.

What are the advantages and disadvantages of each approach?

The advantages are consistency, clarity, and proper enforcement of your API. There are no disadvantages.

Answer 2

As others answered, the HTTP portion of the URL that makes APIs is case sensitive. This follows the UNIX convention, where URI paths were mapped to filesystem paths, and filesystem paths are case-sensitive. Windows, on the other hand, follows its convention of making paths case-insensitive.

However, it is bad practice in Unix to have two paths which only differ by capitalization; furthermore it is expected that paths be lower case.

Therefore: let's not break conventions.

• https://example.org/api/v1/products

and

• https://example.org/api/v1/Products

should never cohexist. Furthermore, products should be preferred to Products. Whether Products should return a 404, a 301 to products or simply be an alias of products is a matter of style -- it's your choice, but be consistent.

Stack Overflow APIs are canonically lower-case and case insensitive. I think this makes life easiest to the client, while having a clear default and being unsurprising for most users.

After all, can you think of a client that honestly benefits from case sensitivity and overlapping names?

Answer 3

HTTP URLs are case-insensitive for the scheme and host portion and case-sensitive for the path, query and fragment.

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19