Tracking Packages with RSS
With the increasing popularity of RSS and Atom, syndication is beginning to be used for many more innovative purposes than simply distributing website updates. In this article I want to show how to simplify such mundane tasks as tracking packages by converting tracking data into an RSS 2.0 feed.
Why RSS?
The first obvious question that comes to mind is why bother with RSS? After all, major U.S. package carriers, including the old-fashioned United States Postal Service, already provide free tracking systems on their websites. To answer this question, one must ask why we use RSS all together. For most folks, including myself, it is a burden to check our list of favorite websites every morning. For some, the list can easily number in the hundreds. Now imagine if you were buying things from eBay, or doing your holiday shopping at Amazon: you might be expecting multiple or urgent packages, and I can bet that most of us will be tracking them pretty often, just like those favorite websites of ours. But if RSS works for website updates, why not serve up tracking information packages in an ready-to-eat RSS feed as well?
Previous Efforts
The idea of using RSS for tracking packages is not mine. Back in July of 2004, Ben Hammersley wrote a screen scraping script for parsing HTML data produced by FedEx's online tracking system into RSS. Unfortunately, screen scraping is often unreliable, since carriers can change their websites at any time. This led to the creation of a UPS tracking service as a .net dll by Jason Young in December of 2004 that utilized UPS's XML API instead of screen scraping. Because I wanted something that would run on Linux without Project Mono, I chose to write my own alternative and with that the track2rss project was born. Current support is provided for FedEx, UPS and USPS, with DHL USA support coming soon. In this article I will be concentrating on the UPS tracking API.
Overview of the UPS XML API
UPS provides two types of tracking APIs for developers collectively called UPS Online Tools: HTML-based and XML-based. The XML API is well documented on UPS's website, (registration required) and only uses XML 1.0, as opposed to SOAP and WSDL. Most other carriers have very similar APIs (although FedEx uses XML schema). The API process consists of an input XML packet sent in the body of an HTTP POST transaction over SSL to the URL provided by UPS. The response packet will either contain an error or tracking information, with an occasional HTTP 500 error for those times when the server is really dead (see an example of an error and a normal output packet).
Astute readers will note that the input packet is actually two XML packets combined together. That is due to the fact that UPS requires authentication information to be passed in a separate XML packet prepended to the actual request packet within the same HTTP request. This authentication data consists of the username and password used to log in to UPS's E-Tools website, and a special "XML Access Key" which must be obtained from the same site.
Note that UPS recommends that the user name and password used for production be different from the regular username and password in order to enhance security. While I understand the inherent need for authentication information, nevertheless I would have preferred that authentication information not include such information or be passed around in plain text even over SSL. The amount of damage that can be done with this information warrants additional precautions be taken by carriers, and with alternatives such as checksums and digests it shouldn't have taken much work to secure these APIs. Additionally, the use of such sensitive authentication information precludes more innovative uses of this API such as accessing it via Javascript. However, since the current API requires plain text user names and passwords, developers should try to securely store the authentication information in their applications.
Project Overview
After obtaining the relevant API information from UPS and registering to get the XML Access Key, I now faced the task of choosing the right tools for translating the package tracking information into RSS. Seeing that UPS's XML API and RSS were just different dialects of XML, I decided to use XSLT, a W3C-standardized language for transforming XML, instead of writing a regular program. One of the main reasons why I chose to go with XSLT is because the XML processing APIs in most popular languages are still too cumbersome for casual use. With a conventional programming language I would need to parse the XML and then transform it into code, while with XSLT I could leave the parsing task to the XSLT processor and do the actual transformation in just a few lines. Additionally, since XSLT and XML are portable across many platforms, I could port my project to any platform. Also, putting XML transformation instructions into an external stylesheet allows for creation of other XSLT stylesheets in the future to generate different types of XML, such as Atom, and easily add support for other carriers without changing the main program.Of course, ending up with a bunch of XSLT stylesheets doesn't do us any good. We still need a way actually execute them. Any other language with XSLT support would suffice for this purpose including Python, Java, .NET languages, etc., as well as any frameworks that support XSLT templates such as Struts or AxKit. However, I decided to write a short wrapper program in Perl because it is portable across many platforms and is available by default on many hosting providers (of course an XSLT processor such as libXSLT is still required). It would be trivial to rewrite the same wrapper in any other language, something that I might do in the future for this project.
Pages: 1, 2 |
