- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
{"fetch":"<frist/>"} for maximum comment backward compatibility.
Admin
Funnily enough, a long time ago I encountered a company that provided a SOAP API to their product.
SOAP, as everyone knows, is intended to hide all the complicated XML stuff and allow a front-end tool to generate objects and methods for you, with the methods taking ordinary arguments etc. So you can then call like any other methods in your program.
Except this company decided to make all its methods take a single string argument that was, of course, expected to be XML format that contained all the numerous arguments. And every method returned a single string that was, obviously, a whole load of XML that you then needed to parse.
Admin
Almost like jsonx from IMB :)
Admin
This is what we call XML-ception.
Though, TRWTF is people do the same thing in JSON fairly often. Web service that return response JSON with some property values being JSON strings...! Unfortunately, JSON-ception is much worse than XML-ception because nested JSON strings get more and more escaped over time, making sure you can never escape the labyrinth of backslashes.
Admin
Possibly a backward-compatibility thing, since I've seen something similar - something that originally started out as XML messages over a generic RPC interface.
It pre-dated SOAP, and was subsequently ported to SOAP not by refitting the XML messaging into WSDL, but by putting a simple SOAP wrapper around the "string in, string out" RPC layer. Not nice, but it did technically solve the compatibility problems associated with the proprietary RPC layer.
Admin
Heh! Backward compatibility.
A few years ago, we dickered about trying to implement a WSRP capability into our product, so we could use WSRP when embedding it into various enterprise servers whose names I can't remember now, but I do know that one of those servers was something in the Microsoft Sharepoint stable. So, we had a few packages to choose from, and I think the only one which looked remotely near to doing what we wanted (that is, to allow apps implemented in any of the commercially available enterprise services to talk via WSRP to one implemented on any other.) (I'm not even sure I have the terminology correct here, so excuse me if I'm talking rubbish.)
Except that nobody was able to get a server which had WSRP v1 implemented on it to talk to a server with WSRP v2 on it. Ostensibly the Apache package did actually implement both versions, but when we got the latest package which supposedly implemented both ... it turns out that all the methods that integrated with WSRP v1 had been carefully amended so as to contain nothing but "return null".
So much for backward compatibility.
Long story short, we gave up on that project and invested effort into something else instead. That was about 8 years ago, though, so life may be different now.
Admin
Oh I just had to implement such an API. There were multiple endpoints all in wonderful JSON with a proper Swagger documentation. However certain data was not available but was promised in an earlier workshop where the sales team of course promised it. We knew they had an old XML based web service that would return it, but we did not have the license for that. So I sent our PHB to their PHB to have them negotiate out what we will get and what we will pay. Two months later I had a new JSON endpoint to retrieve the data. I sent the first request and got a wonderful response along the lines of { "id":1234,"xml":"<xml>....<the data in xml as escaped string> ....</xml>"}
I have to assume that the developers just hadn't built the JSON endpoint yet and their PHB made them create such an endpoint asap as they had already sold it to us.
Admin
Funnily enough, a long time ago I encountered a company that provided an XML API to their product as an "improvement" on their binary interface. Of course the XML used a single tag <data>A0FC2A.......</data>. I guess we can assume that the exact same idiocy has been used by now in every possible combination.
Admin
Maybe. Probably not though. There's still too many people kicking the can of shit down the road and not enough time to do the job right.
Admin
So a working and long established system creates XML, then someone demands JSON [probably without any business purpose other than buzwordiness], and wants it yesterday, so there's a quick hack to stuff the data into that format.
Admin
I've had to work with a couple XML APIs. Not real XML, XML in the "Status" parameter of a application/x-www-form-urlencoded post. Apparently they didn't know there were other content-types.
Admin
I generally find the articles entertaining, but this one genuinely had me laugh. Like a good joke: Shirt, but genuinely funny.
Might be interesting to find out how it happened though. ICanBeARobotIfYouWantMeToBe probably has the right guess.
Admin
I wrote an extensive (30,000 lines, ish) project in assembler for a small embedded system. At the last minute, they told me it was supposed to be written in 'C'. I suggested to them "asm: { <assembler codebase here> }" (syntax varies with compiler) would technically solve the problem, but they really didn't like that idea.
The C rewrite was a disaster on its own rights also, but that's another story. J.
Admin
Think about this. They outdid themselves. They provided XML and JSON in one shot! Two for the price of one. This is a killer deal if I ever saw one.
Admin
The API that I maintain is inherently XML but has JSON as an option. When using JSON it will convert the JSON into XML, process it, and then convert the returned XML into JSON. Quick and dirty and it worked until clients started using massive datasets and the servers ran out of memory. It now works more directly but there's still vestiges of the XML in the JSON - mostly on how arrays are nested - but not like TFA.
Admin
Yeah, something like that.
We had exactly the same shower dropped onto us at the end of last year, with a brief that all work needed to be complete by February. So of course we have all these new integration points, all with (supposedly) a neater and more efficient and programmer-friendly API. Except it's not. Oh yes, while the JSON objects are smaller than the XML ones they replaced (which is a good advantage JSON has over XML), the implementation team they got to work on recreating the integration points were, not to put too fine a point on it, donkeys. And not in a good way either. They're still arguing over the spec for how the error handling is supposed to work (mind, they've been doing that for several years), they were never able to work out how to use the tool they were given to perform pre- and post-processing of data (so we have to do a lot of munging in the front end), and last but not least they forgot to implement any techniques for returning general sorting and filtering on the data to be returned (which was red-hot priority when we first built the XML-based version a year or two back).
Ho hum. I'm out of all that now -- I've changed position. So to speak.
Admin
A system only being capable of returning XML is as much working as a bone fire in a cave would be considered a light source. Technically it is, but ...
Admin
Funnily enough, I happen to work on a product where we consume not just one, but two of those monstrosities by different companies, which provide the same service for different customers.
They also take almost, but not totally, the same data in their internal XML document, in almost, but not totally, the same format.
Also, all data that could theoretically be passed as short identifiers, e.g. countries or nationalities (which are not the same!), have to be passed as the name as it appears in their database, which requires all kinds of "fun" mapping.
Admin
I maintained such an API for Fortune 100 company. They had pages and pages of documentation showing how to create the XML. Numerous companies came to depend on it. I've even seen job listings asking for expertise in dealing with this one API.
Other business appeared that sold a front end to our API, aggregated with similar APIs from our competitors. They sold this, and if their customers ever reported a problem, they just tell them to tell us. We'd get a Help Desk ticket saying that a customer tried to use some 3rd party tool and got an error.
The error message wan't from our application - it was from theirs. So it meant nothing to us. At the same time, the actual cause of the problem might be within an XML document that person reporting the problem didn't know about and didn't even know existed, because they didn't use our API. They used the aggregator.
Did I say "was?" All of this stuff is still running. Years ago we switched from a mainframe to a newer ERP and carefully replicated the same API with the new ERP, thereby ensuring that it would never die. And we had to keep the mainframe version running too.
Admin
Perfect solution for a non-existent problem. They could have simply said "we won't change the file-format just because JSON in trendy now" but that would have impolite.
Admin
all they needed was an xslt on the client to convert xml to json (you could do that server-side, but why waste your own resources when you can waste the user's).