• 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)
    Comment held for moderation.
  • (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)
    Comment held for moderation.
  • Joe (unregistered)
    Comment held for moderation.
  • (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
    Comment held for moderation.
  • 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)
    Comment held for moderation.

Leave a comment on “JSONception”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article