One thing that has continually plagued my fellow colleagues and I are "special characters". These are things like ", #, &,
\, @, and any other character that one might include in a string literal but which may have special meaning in another context.
For instance, in strings, a quote (") is a delimiter, so one must escape it in order to tell the interpreter/compiler to interpret it literally. Likewise, in URLs, an ampersand (&) acts as a delimiter in query strings to separate key/value pairs, and one must URLEncode the character in order for the HTTP parser to interpret the ampersand literally.
Then we have HTML encoding, which is necessary when telling the HTML parser to treat the HTML as a string literal. In fact, even in Stack Exchange's markdown, in order to print HTML, I must tell the markdown parser to
<p>Interpret this literally</p> by putting it inside a code block.
I really really want to solve this problem so that we can be confident an end-user can't break the system and have poor user experiences. So I put together an automated test I can run on my API that loops through all 255 ASCII characters and submits them as data to the API. As expected, 1 through 31 fails, so we ignore those since they're known, non-printable characters. But when I ran the tests from ASCII codes 32 through 255, I was pleasantly surprised to see that all of them worked, with the exception of codes 34 (") and 92
(\). (Note that even the backslash must be put in a code block in markdown!)
It seems that my deserialization libraries on the server side, which convert JSON strings into objects, were getting hung up on the quotes and the backslashes, since they have special meaning inside a string. This brings me to the Robustness Principle, as stated by Wikipedia:
"Be conservative in what you send, be liberal in what you accept".
With that in mind, whose job is it to handle processing quotes and backslashes? Is it the server's responsibility to handle every piece of unencoded data, or is it the client-side's responsibility to make sure the URLEncoded quotes and backslashes are also escaped so they won't be interpreted as delimiters and escape characters in a string? To answer this, let's assume the server-side could be developed in any language on any platform.