I had this happen with a vendor that was told that they needed to add REST support to their legacy Java app. They turned up with an API that encoded XML as base64 and put that in a POST variable on HTML page. Then they added their own crypto on top with hard-coded RSA keys. They helpfully included both the public and private keys in their documentation.
When they turned up for a meeting to present the fruits of their labour they got patted on the back by all the managers for a job well done. Record time too!
They faces fell when I told them that I'm flat out rejecting their API design and that they will have to start from the beginning.
Their excuse for the design was that ampersands are too hard to process, so base64 encoding made them "safe" to include in the REST API.
Sometimes you just have to put your foot down about this kind of idiocy.
Unfortunately I have vivid memories of one API I worked with (many years ago) that included entire encoded XML documents as attribute values within top level XML. At least there was only one level of recursion.
Still, perhaps not as bad as using XML documents as database keys...
Receiving XML that is almost valid can be a real pain - it certainly used to be that some XML parsers didn't report some weird errors in a particularly helpful way requiring manual scrutiny.
I have unpleasant memories of trying to work out why some SOAP web service was breaking and it turned out the WSDL was invalid in a subtle way.
I've needed to do that for HTML. If you need to put part of a document inside an iFrame (perhaps because you don't trust it) you have your backend generate <iframe sandbox srcdoc="..."> and nest it.
When they turned up for a meeting to present the fruits of their labour they got patted on the back by all the managers for a job well done. Record time too!
They faces fell when I told them that I'm flat out rejecting their API design and that they will have to start from the beginning.
Their excuse for the design was that ampersands are too hard to process, so base64 encoding made them "safe" to include in the REST API.
Sometimes you just have to put your foot down about this kind of idiocy.