To XML or not to XML?
If you do any interaction between web applications, or even if you just use AJAX to query data in a background thread, you have to choose what format you want to use to send/receive data. When thinking about data wrappers there are usually about 4 obvious options:
XML. This is was the “right” way to send data, at least that’s what the kids have been telling me. It’s great when you have complicated data to send, like full HTML that you need to wrap into a container for an RSS reader. It’s a royal pain when you have to instantiate a huge XML parser that supports every crazy CDATA feature under the sun just to parse something like this:
<record>
<firstName>John</firstName>
<lastName>Smith</lastName>
<ordersThisYear>5</ordersThisYear>
</record>
Thankfully developments like simplexml have made the overhead for such operations much more manageable.
HTTP POST. While a lot of people might scoff at the POST, it’s surprising how often data interfaces use this method. Every credit card merchant provider I’ve integrated with has at least had a POST interface as an option, if not the only option. This is usually a pretty easy and lightweight solution, but you can run into limits with large records, and it’s far less easy to read as a human than XML or other options. Also, it’s not easy to speak in POST both ways. I can POST to you, but the data you give me back is probably going to be XML, JSON, etc.
I’ve seen another hybrid XML/POST method where I POST XML data to you, ala http://www.example.com/?xml=<record><firstName>John</firstName></record>
JSON. This is my new favorite data wrapper. One thing to love about JSON is that (as the name implies) you can easily bring your data into javascript. This means that you can have one interface on your backend for both bringing in data to your AJAX front-end and communicating with third parties via a web-facing API. If it’s formatted well it’s just as human-readable as XML.
Roll Your Own. Favorite of prima-donnas everywhere, the Roll Your Own method is usually a waste of time, but occasionally the best solution to a tough problem. Have a data method that has particularly special constraints? Maybe it’s time to roll your own, but probably not. There isn’t much that you can’t fit into one of the above methods, and the libraries already exist, saving you time (and hopefully money).
Pick your wrapper carefully, as you’ll end up supporting it forever when that one big customer is still “trying” to upgrade their system to work with your new API methods.