Enterprise Webservice API (now with XML!)



  • I could write a whole book about the WTFs in software from this company. Actually, I should just post the manual. Here's one to start us off.

    The API uses XML syntax over HTTP (or HTTPS) protocols, and any programming language that can make TCP/IP requests can be used to access the API. JAVA, PHP, ASP and many other languages include XML libraries that simplify the syntax of our API.

    Hmm, that sound OK. Is REST? SOAP? Oh, I don't think so..

    Using HTTP Post to the specified url with the following parameters: type=query and activity=query-data. URL encode the following payload:

    <DATASET>
    <SITE_ID>123</SITE_ID>
    <MLID>345</MLID>
    <DATA type="email">foo@bar.com</DATA>
    </DATASET>

    the server responds with:

    <DATASET><TYPE>success</TYPE>
    <RECORD>
    <DATA type="demographic" id="1">Foo</DATA>
    <DATA type="demographic" id="2">Bar</DATA>
    <DATA type="demographic" id="3">Baz</DATA>
    <DATA type="extra" id="state">active</DATA>
    <DATA type="extra" id="statedate">2006-01-01</DATA>
    <DATA type="extra" id="uid">8474562938</DATA>
    </RECORD>
    </DATASET>

    Put every field from the query into a DATA tag--brillant! Then, take it a step farther and make it very difficult to figure out what the field name actually is (is it in "type" or "id"? Or is it one of the many special cases?). Awesome!

    p.s. And if you make any mistakes in the query, it returns... nothing!



  • I'd also like to add that, depending on the field, dates are stored in any of the following formats: "20060802", "2006-8-2", or, of course, UNIX Epoch.



  • @esd said:

    Using HTTP Post to the specified url with the following parameters: type=query and activity=query-data. URL encode the following payload:

    <DATASET>
    <SITE_ID>123</SITE_ID>
    <MLID>345</MLID>
    <DATA type="email">foo@bar.com</DATA>
    </DATASET>

    the server responds with:

    <DATASET><TYPE>success</TYPE>
    <RECORD>
    <DATA type="demographic" id="1">Foo</DATA>
    <DATA type="demographic" id="2">Bar</DATA>
    <DATA type="demographic" id="3">Baz</DATA>
    <DATA type="extra" id="state">active</DATA>
    <DATA type="extra" id="statedate">2006-01-01</DATA>
    <DATA type="extra" id="uid">8474562938</DATA>
    </RECORD>
    </DATASET>



    How brillant. Dear siree, could you tell us how to URL-encode the following -
    <DATASET>
    <NAME>þàùŁ
    à</NAME>
    </DATASET>



  • I should also add that it doesn't escape any characters on the backend. So if any tags or even a "<" show up in the data, it makes life very tough on the parser.

    Oh, and for any one-to-many relationships you either get: multiple identical columns or one column with all the data combined like "first item||second item||third item". As usual, it depends on the query. Pretty much every query is a special case.



  • Sounds familiar.  The company's name wouldn't happen to be a set of initials, the first letter of which is S, would it?



    One memorable nasty was some data that was transmitted with elements like the following:



    <dataItem1 text="Some text"/>

    <dataItem2 text="Some more text"/>

    <dataItem3 text="Miscellaneous"/>

    <dataItem4 text="You get the idea"/>



    The best part?  The number of items varied with each
    transmission.  Validation (against a DTD or schema) was
    impossible.  The point of XML was clearly lost on the format's
    creator.




  • @esd said:

    I should also add that it doesn't escape any characters on the backend. So if any tags or even a "<" show up in the data, it makes life very tough on the parser.


    Ouch.  People like the Flat File Society (search the old WTFs) abusing XML is one thing.  But if your bad XML isn't even valid XML, there's absolutely no value in having it in an XML-esque format.



  • @merreborn said:

    Ouch.  People like the Flat File Society
    (search the old WTFs) abusing XML is one thing.  But if your bad
    XML isn't even valid XML, there's absolutely no value in having it in
    an XML-esque format.
    Your problem is that you're thinking like a logical person.

    Put yur marketing hat on, and you'll realise that the difference
    between good XML and bad XML is.... huh? What are you talking about,
    it's XML! That means another fancy buzzword in the brochure. ALL XML is
    good XML.



  • @RayS said:

    Your problem is that you're thinking like a logical person.

    Put yur marketing hat on, and you'll realise that the difference
    between good XML and bad XML is.... huh? What are you talking about,
    it's XML! That means another fancy buzzword in the brochure. ALL XML is
    good XML.


    Personally, I operate on the principle that all XML is bad XML. That means I might as well just take my regular data and shove it in one big CDATA block, thereby satisfying the requirements.



  • The real WTF is that it is not namespace aware.


    <DATASET
    xmlns="http://www.enterprisesolutions.com/ultimate-super-format/"><TYPE xmlns="http://www.enterprisesolutions.com/ultimate-super-format/">success</TYPE>

    <RECORD
    xmlns="http://www.enterprisesolutions.com/ultimate-super-format/">

    <DATA
    xmlns="http://www.enterprisesolutions.com/ultimate-super-format/" type="demographic" id="1">Foo</DATA>

    <DATA
    xmlns="http://www.enterprisesolutions.com/ultimate-super-format/" type="demographic" id="2">Bar</DATA>

    <DATA
    xmlns="http://www.enterprisesolutions.com/ultimate-super-format/" type="demographic" id="3">Baz</DATA>

    <DATA
    xmlns="http://www.enterprisesolutions.com/ultimate-super-format/" type="extra" id="state">active</DATA>

    <DATA
    xmlns="http://www.enterprisesolutions.com/ultimate-super-format/" type="extra" id="statedate">2006-01-01</DATA>

    <DATA
    xmlns="http://www.enterprisesolutions.com/ultimate-super-format/" type="extra" id="uid">8474562938</DATA>

    </RECORD>

    </DATASET>


Log in to reply