Fun With Web Services: PostalMethods (Part 1)

The Web Services hype is over and its usage in production software and services is a reality.  We implemented both flavors of Web Services (SOAP and REST) in our EBI product because we knew Web Services would be very useful to our customers in the integration world.  Users can configure EBI to use Web Services to invoke APIs from public services.  The purpose of this blog is to focus on one of these public Web Services:  PostalMethods.  From their website:  “PostalMethods is a convenient web-to-post gateway which makes it easy for businesses to automate the sending of postal mail from business applications.”

For those unfamiliar with Web Services, click here.  To summarize, a Web Service is a way for disparate systems to communicate with each other over a network.  Information is transmitted most of the time by using the web protocol HTTP.  XML is usually the message format for the payload, but any format can be used.  When using Web Services, you must decide which type of Web Services to use:  SOAP or REST.  A blog about each of these Web Service types along with their advantages/disadvantages written by Dave Ogozalek is available here.

I discovered PostalMethods from reading one of my favorite Java tech news sites  PostalMethods provides a variety of protocols and APIs that allow software to send documents to PostalMethods, and they will automate the process of formatting the document, printing it out, folding the paper(s), stuffing it into a pre-stamped envelope, sealing the envelope, and mailing it off to the post office.  This service is a great example of why I got into the software development field:  to offload mundane work to automated systems so that people’s time can be freed up to complete more interesting tasks.

Before proceeding, I needed to address two concerns:

  1. How complicated is their Web Services implementation?
  2. What file formats were supported?
  3. How do I send the recipient’s address?  Is it embedded in the document, or do I submit that information separately?

PostalMethods supports both SOAP and REST, so now it is only a matter of deciding which implementation is better.  Their SOAP approach is better because the information structured submitted to PostalMethods is easier to read in XML instead of reading everything on one URL query line.  The problem I have with PostalMethods’ Web Service implementation is that it requires base 64 encoding the payload.  Many other systems use this approach to get around the problem of transmitting binary data in a SOAP message.  The disadvantage to this approach is that extra processing is required to encode the data in base 64, and transmission times increase since base 64 encoding increases the file size by about one-third its original size.  I wish PostalMethods would have implemented a cleaner REST approach by allowing the data to be transferred in the request body so that the data could be sent unmodified, or else support the SOAP with Attachments specification for transferring binary data unmodified in a SOAP message since EBI also supports this.

Excel is on the list of supported file types, so EBI will have no problem working with PostalMethods since EBI supports Excel.

In my next blog, I will answer #3 and discuss how the document was constructed and sent to PostalMethods via EBI.  I will also talk more about some of the features PostalMethods offers its customers.

One thought on “Fun With Web Services: PostalMethods (Part 1)

  1. Pingback: uberVU - social comments

Leave a Reply

Your email address will not be published. Required fields are marked *