3 ms·

Or you could do what one API I just discovered does: embed escaped XML inside JSON! We truly live in a world

breakfastduck 3y ago
I have worked with a supplier / service who advertised us their brand new shiny REST/JSON based API that we could use to replace the drop a csv in a sftp workflow they offered previously. The API was a post with a single JSON field called data, with a CSV string value. You just know they were asked by management to deliver an API and decided to do quite literally the minimum viable. They had 'no plans' to expand it.
- cgio 3y ago
  How anyone would see that as a MVP when you can make a pretty solid API with Postgrest eludes me.
  - crgwbr 3y ago
    It’s MVP because it (1) is an API and (2) is doing nothing more than writing it’s output to the same sftp server the client used to hit directly. Not debating it’s dumb, but almost by definition enterprise tech ossifies in weird, dumb ways.
- hyperman1 3y ago
  I've seen similar in the wild with XML, except the charset was wrong and escaping was incomplete. So you get the XML header with UTF8 encoding, a root tag, an indented child tag. 3 lines. Then ye olde CSV, with the 5 required entities for ascii escaped, but if you manage to put accented chars in it, they end up in ISO 8859-1. Then 2 lines footer. If you wrote out the file, the header and footer had to be byte for byte identical. Entities encoding non ascii just crashed the parser. Of course, the CSV lines were sensitive to indentation, they just dropped the first 8 chars of each line. Still, XML was officially supported.
icedchai 3y ago
I've seen base64 encoded XML embedded inside a form post. I think it was for SAML? I was truly horrified.
- breakfastduck 3y ago
  the fun truly starts when you get escaped xml inside xml attributes
- paulddraper 3y ago
  Yes, that is for SAML. But... What do would you do instead?
  - icedchai 3y ago
    Yep, you’re right. Not much of a choice given the limitations of HTML forms, etc.
- magicalhippo 3y ago
  So many seem to have "base64 damage", they get confused when they don't have to base64 encode something. To attach documents (e.g. scans) to a given order in our API, you just POST the raw file directly to the endpoint with appropriate content type. Simple. Yet I get so many questions like "but we base64-encode them first?" or similar. One dev mentioned he'd never done such a "raw" POST.
  - icedchai 3y ago
    There's a lot of weird APIs out there. I've seen some where a file is uploaded by base64 encoding it and putting it into JSON: { "file": base64blob }
taeric 3y ago
We had the encoded JSON in JSON causing gigs of slashes not long ago...
- klysm 3y ago
  I’ve seen this way too many times. Idk what to call it, double serialization? It’s incredibly annoying though
wolpoli 3y ago
I had one that looked like someone converted XML directly into JSON and I had to parse the XML like structure without the benefit of an XML library. Not surprisingly, they didn't put any example JSON in their API documentation.

I have worked with a supplier / service who advertised us their brand new shiny REST/JSON based API that we could use to replace the drop a csv in a sftp workflow they offered previously. The API was a post with a single JSON field called data, with a CSV string value. You just know they were asked by management to deliver an API and decided to do quite literally the minimum viable. They had 'no plans' to expand it.

cgio 3y ago
How anyone would see that as a MVP when you can make a pretty solid API with Postgrest eludes me.
- crgwbr 3y ago
  It’s MVP because it (1) is an API and (2) is doing nothing more than writing it’s output to the same sftp server the client used to hit directly. Not debating it’s dumb, but almost by definition enterprise tech ossifies in weird, dumb ways.
hyperman1 3y ago
I've seen similar in the wild with XML, except the charset was wrong and escaping was incomplete. So you get the XML header with UTF8 encoding, a root tag, an indented child tag. 3 lines. Then ye olde CSV, with the 5 required entities for ascii escaped, but if you manage to put accented chars in it, they end up in ISO 8859-1. Then 2 lines footer. If you wrote out the file, the header and footer had to be byte for byte identical. Entities encoding non ascii just crashed the parser. Of course, the CSV lines were sensitive to indentation, they just dropped the first 8 chars of each line. Still, XML was officially supported.

icedchai 3y ago

I've seen base64 encoded XML embedded inside a form post. I think it was for SAML? I was truly horrified.

breakfastduck 3y ago
the fun truly starts when you get escaped xml inside xml attributes
paulddraper 3y ago
Yes, that is for SAML. But... What do would you do instead?
- icedchai 3y ago
  Yep, you’re right. Not much of a choice given the limitations of HTML forms, etc.
magicalhippo 3y ago
So many seem to have "base64 damage", they get confused when they don't have to base64 encode something. To attach documents (e.g. scans) to a given order in our API, you just POST the raw file directly to the endpoint with appropriate content type. Simple. Yet I get so many questions like "but we base64-encode them first?" or similar. One dev mentioned he'd never done such a "raw" POST.
- icedchai 3y ago
  There's a lot of weird APIs out there. I've seen some where a file is uploaded by base64 encoding it and putting it into JSON: { "file": base64blob }

taeric 3y ago

We had the encoded JSON in JSON causing gigs of slashes not long ago...

klysm 3y ago
I’ve seen this way too many times. Idk what to call it, double serialization? It’s incredibly annoying though

wolpoli 3y ago

I had one that looked like someone converted XML directly into JSON and I had to parse the XML like structure without the benefit of an XML library. Not surprisingly, they didn't put any example JSON in their API documentation.