• Farrah (unregistered)

    If they need to treat the subdocument as a blackbox and properly encode it and decode it, what is wrong with that?

  • some guy (unregistered)

    I was in the process of doing basically the same, but it was late at night and I was on Ibuprofen AND I stopped myself BECAUSE it felt so stupid. Then I did the sub-object approach.

  • DQ (unregistered)

    WTF, I just encountered the same thing yesterday. Was thinking of sending it in...

    {

    "result": "{"result": [{"interview_id": "996395", }",

  • Hanzito (unregistered)

    There are two things in the world I can't stand: JSON strings in JSON... and the Dutch.

    (I'm pretty sure begin_datum and eind_datum are Dutch, even though they are misspelled).

  • (nodebb)

    I mean, they could have embedded XML as a string inside of a JSON, so this isn't the worst?

  • Vera (unregistered) in reply to Hanzito

    Both are correctly spelled in Dutch, yes. So, most likely a Dutch interface.

  • guest (unregistered)

    Better than the industrial IOT device I had to deal with recently. Their website: "In addition to a custom binary wire protocol, we support sending measurements as JSON via MQTT". The JSON:

    { "data": "0x......." }

  • Black Mantha (unregistered)

    I haven't encountered this, but I have encountered xml encoded as an xml string. Biggest surprise was that they didn't also base64 encoded it.

  • (nodebb) in reply to Hanzito

    I'm pretty sure begin_datum and eind_datum are Dutch, even though they are misspelled

    Yes, that's Dutch. Not misspelled, but you can argue about snake_casing in json.

  • Hanzito (unregistered) in reply to nerd4sale

    "begindatum" and "einddatum" are one word. No spaces, no underscores, no hyphens. But the end point won't care, of course.

  • (nodebb)

    If they are using JSON references, then they might have issues just embedding one JSON document within another. In that case coding as a string is a "reasonable" work-around.

  • Bob (unregistered)

    To be fair, if the embedded JSON is from some place notorious for hand-crafting broken JSON strings, this is a good way to hand it over without having to deal with the embedded idiosyncracies.

  • rosuav (unregistered)

    Could be worse. You could have a Base64 nonce that, when decoded, contains a JSON object with two keys, which are also Base64 strings... of JSON.

    eyJiIjp7IkN1cnNvciI6ImV5SnpJam8yTVRJeE9DNDFPREEyTmpRMU5UazROeXdpWkNJNlptRnNjMlVzSW5RaU9uUnlkV1Y5In0sImEiOnsiQ3Vyc29yIjoiZXlKeklqbzVOamczTGpFMk9URTNNamsyTVRnek5Dd2laQ0k2Wm1Gc2MyVXNJblFpT25SeWRXVjkifX0

  • Foo AKA Fooo (unregistered) in reply to rosuav

    That's how you do it: https://thedailywtf.com/articles/edoced-46esab

  • (nodebb)

    I see embedded JSON like this all the time in Stack Overflow questions. It's unfortunately too common.

  • Mathieu (unregistered)

    This reminds me of the save files from the Final Fantasy Pixel Remaster collection. There is at least 5 level of JSON embedding, with tons of typos as a bonus.

  • (nodebb)

    Could be worse. They could have included comments. And encoded comments in the embedded json.

    (Put the keyboard down. I am aware that the json spec doesn't support comments. That's the joke.)

  • TrueWill (unregistered)

    And then there's https://jsonnet.org/ ...

  • Joe (unregistered)

    Count me in as someone who doesn't think that JSON embedded as a string in JSON is always unreasonable. It's kinda ugly and wonky, but if the JSON is tiny and basically never changes, who cares? Most of the WTFs on this site fall into some category of either it doesn't work as intended or it's inefficient by an order of magnitude (creating a new database connection for every SQL query executed in a loop, for example), and this doesn't really qualify, IMO.

  • (nodebb)

    Another "Me Too" here - a system we use does that for the interface to run custom functions.

  • (nodebb)

    Banking applications are notorious for using XML. I had a finance client that used a service that took it one step further. What was essentially an XML-RPC call (although following their own conventions) turned the inner data into an XML handshake sequence. Then, an outer "transport layer" was used for session management. It took the inner conversation's payloads and added an entirely new level of XML. Yes, double encoded everythings. And it didn't handle CDATA properly so I couldn't even use that. Ugh. (This came about because a large bank-networking company had purchased a smaller bank-networking company, and they had to support both layers of interface.)

  • Scragar (unregistered)

    May previous place of work used XML embedded in JSON, which was then embedded in an XML document for it's API.

    Each of which took the anti pattern of having a "success" attribute that needed to be checked in case something fell over(because returning a HTTP error is too complicated).

    The reasoning was that they started with a poorly defined XML API, then decided JSON was better since they had no advantages from XML anyway and migrated basically nothing to it instead just wrapping up the old responses in a JSON wrapper. Then a few years down the line decided they should move back to XML so they could use custom doctypes to define the response/request format, so they moved back, but again swapping things over fully was too much like hard work so most of the APIs just got wrapped in a new XML layer.

    Giving us wonderful API responses like

    <!DOCTYPE wrapped_response SYSTEM "https://api.domain.com/v4.1.dtd">
<wrapped_response>
    <success>TRUE</success>
    <body>
        {
            "success": "true",
            "xml": "<root><success>TRUE</success><data><num_results>0</num_results><results/></data></root>"
        }
    </body>
</wrapped_response>
  • (nodebb) in reply to Scragar

    I hate you.

  • (nodebb)

    I hate it, but it's so common I don't even think of it as a WTF anymore...

  • (nodebb) in reply to Scragar

    It's positively horrifying

  • Your Name (unregistered) in reply to Scragar

    HTTP codes are for the HTTP layer. I do not understand how someone pondered the glorious idea to partially misuse these as result for the inner protocol. DO NOT THE FUCK DO THAT.

    404 - Did you hit the wrong end point, or was the request technically valid but some entity could not be found? How to differ?

    http 200 OK - The Technical request was fine, everything else MUST be handled by the inner protocol. Do not mix.

    You wouldn't use the system error code on the command line for the size function for files < 256 bytes.

  • Yazeran (unregistered)

    Well it's nice to see that not only XML allows for inception .. (ref https://thedailywtf.com/articles/double-bagged )

    Yazeran

  • (nodebb) in reply to Scragar

    Reckon says, "Hold my beer!" :P

    I don't know if Intuit went that way with Quickbooks itself, but Reckon certainly decided to wrap the QBXML in a JSON request.

  • FW Tuesday (unregistered)

    I have to deal with this so often I checked the data to make sure this wasn't me...

    Annoyingly, this kind thing happens a lot in the world of ERP and such where we're often working inside "sandboxes" or dealing with "managed" communication. e.g., I can define custom REST endpoints in system ABC, but their tooling only allows primitives as parameters. So... fill that string up with JSON. And being a REST endpoint, that string is already part of a JSON payload.

    Luckily, this works extremely well. No one ever changes the 'JSON schema' without telling people. And no one ever gets headaches.

  • Osric (unregistered)

    Personally I hate the pattern, but I've encountered it enough in APIs that I have no control over that its not terribly shocking.

  • (nodebb)

    I would strongly disagree that this is the wrong thing to do.

    If at this abstraction level that json is data then it should be held as data. The fact that data happens to be json shouldn't matter.

    You might deserialise the json into your DTO objects and the data would be a string to do whatever with. If it was json your DTO object would have to have objects to represent it despite you not caring about what it is (and presumably reserialising it before sending it on); it might even be variable arbitrary structure making things unnecessarily painful.

    E g. {"ProgramToUse":"jsonEater", "configData":"someNestedJson", "timeToRun":"9AM"}

Leave a comment on “JSONception”

Log In or post as a guest

Replying to comment #682572:

Log Out

« Return to Article