StrikeIron Blog

Managing API Response Code Complexity

When a Web service API is invoked across the Web (or across the enterprise), a response code is typically returned from the Web service indicating a successful invocation, a failure, or providing some other kind of information being reported by the service, such as invalid password, data not found, etc.

This seems fairly straight-forward, you ask a question and you get a response along with a code on how to interpret that response. However, if you have ever built an application or Web site using multiple APIs and Web services, especially from different vendors, you know that there are very few steadfast rules around what these various response codes can be. This means new levels of complexity can be introduced into Web applications when having to create code and logic to handle all of the various response codes your application might receive from various external service calls. This is counter-intuitive because the whole point to using external services in the first place is to reduce complexity and make things simpler, not create new complexity.

For example, the simple response code from a data service of data not being found in response to a query on the Web today includes variations such as “0”, “error 100”, “404”, the “data not found” string, nothing at all being returned, and probably about a thousand other possibilities. These responses must all be anticipated and understood by the consuming application. A programmer (or a business user) that must incorporate all of these differing responses into an application, Web site, third party application, or mashup is facing a tall order.

One of the things we have done at StrikeIron to alleviate this burden is to ensure that all of the various response codes returned from our commercial Web services are consistent across all of these services, significantly reducing complexity for anyone putting them to use.

For example, StrikeIron APIs will return a Status Code of 200 for all successful invocations. Here are some other basic examples of status codes that are consistent across all services.

    * StatusNbr = 200 StatusDescription = Found
    * StatusNbr = 300 StatusDescription = Not Found
    * StatusNbr = 500 StatusDescription = Internal Error

Of course, each service has its own range of service-specific response codes that fall within these number ranges (such as carrier not found for sending an SMS message, or invalid zip code for an address verification), but you will find consistency in these responses as well. You can check the documentation (or invoke the status code methods within the service) for a full list of response codes for any given StrikeIron service.

The general idea is that this consistency makes it easy to move from one API to the next while minimizing any amount of learning curve, and getting us all closer to the to the goal of reduced complexity we are all trying to get to in the first place.

Post Eloqua Experience Notes and Multi-Channel Marketing with SMS

If you don't already know, Eloqua is a Web-based marketing and campaign management platform for lead nurturing, lead management, and campaign effectiveness measurement, all focused primarily around email. If you are trying to optimize the time of your sales organization (and who isn't), it would be a good idea to learn the concepts of "lead scoring" and "lead nurturing" to maximize sales team effectiveness.

A very simple example of lead scoring might include more "points" given for someone who lands on your Website after searching for your company name, rather than just a generic search term (clearly they were interested in specifically your company). This could be one of several factors affecting a "lead score". Then, depending on a lead's score, different sets of business rules might be applied (such as a phone call versus a follow up email). A good primer for this kind of approach is the book by Eloqua Founder Steve Woods entitled Digital Body Language.

Members of the StrikeIron team attended the Eloqua Experience user conference last week in San Francisco where they showcased Eloqua's integration of our SMS Text Messaging capability. It is a key component of using Eloqua for multi-channel marketing purposes. SMS can be used in a multi-touch lead nurturing program using various communication channels to nurture leads through the initial stages of the buying process.

Here is a screen shot showing how mobile text messages can be sent via template within the Eloqua platform:

All you need to do is come to StrikeIron to get your UserID & Password credentials, and then plug them into the Eloqua product, and you can start sending text messages globally (we handle all of the backend SMS capabilities and billing, supporting hundreds of carriers in hundreds of countries with fast, reliable message delivery).

At the event, to help showcase the SMS capability within Eloqua, DemandGen (one of our partners) created an SMS bingo game. Numbers were drawn during various sessions breaks and lunch to put a high tech spin on the classic game of Bingo, all done via SMS.

David Meerman Scott gave a good presentation at the Eloqua event as well that I continue to hear great things about. I would highly recommend new world marketers follow his blog and also follow him on Twitter.

Glimpses of the latest cut of the Eloqua product and platform demonstrated a really nice user interface, powerful reporting capabilities, and the ability to easily leverage non-email channels (such as SMS) as an effective part of any lead maximization strategy. While there are other choices to consider in the space, Eloqua is one of the best.

The Wallet in the Cloud for Ecommerce? Paypal Launches X.com

Paypal announced today at their first ever developers' conference the launch of their new developer platform called "X". It is now available for developer signup at www.x.com. This "wallet in the cloud" offering introduces the concept of "Adaptive Payments" that can be embedded in just about anything, geared towards abstracting payment system complexity from developers building applications and Websites that collect funds for goods and services. It also introduced "Adaptive Accounts", enabling PayPal accounts to be auto-created on behalf of your customers.

These offerings are built around the launch of a new offering of APIs (not all of which are entirely new) aimed at making PayPal a ubiquitous mechanism for buying anything, anywhere and substantially increasing the types of business models PayPal can now support. For example, Adaptive Payments ideally will enable such fun as buying directly off of TV's from your remote control, buying via smartphones, kiosks at the mall, at restaurants, within a car (pay tolls with PayPal?), or anyplace or anything else where it is physically possible to enter a Paypal email address and password.

Paypal currently accounts for about $70 Billion dollars per year of the $30 trillion annual global spend. This represents about 15% of the total ecommerce market. Clearly eBay (PayPal's parent company) believes there is a lot of room for growth and additional vehicles of commerce to capture. They insist that cash is dying a slow death and our grandchildren won't know what it was like to carry around cash, and other types of paper currency (such as checks) are becoming obsolete. PayPal is banking on opening up their platform and payment networks to an army of developers, and that this will lead to a wave of new online innovation with PayPal payment mechanisms at the core. With 240 million accounts now on PayPal, 80 million of which are active, it is a difficult theme for online vendors to ignore.

At StrikeIron, we follow ecommerce developments closely because of our many complementary APIs to ecommerce systems like Paypal, including everything from sales tax rates APIs, address verificationglobal too), email verification, telephone number verification and enrichment, currency rates, and even the ability to send SMS messages and text-to-voice messages to landlines to let people know that packages should have arrived for example for a better customer experience. These are all necessary components for those wishing to create an optimized ecommerce transaction and the best possible user experience. Everything that drives more ecommerce to occur is ultimately driving more need for own Web-based ecommerce SOAP and REST services, so we do everything we can to make sure our own APIs are compatible with and what our customers are using, need, and want. Hence our interest in developments at PayPal.

The new platform is already being put to use as was showcased during the event at the keynote presentations. I really enjoyed seeing SAP's demonstration of their new adoption of Paypal for B2B applications (they now have a PayPal module within R/3), enabling invoices to be generated within SAP, and then payment to be remitted and received via a Paypal account - all in a few simple clicks.

ShopSavvy had a nice iPhone application that enables one to search for a product, get a list of all online vendors selling that product sorted by prices, and then buy from the vendor of your choice. This is all achieved in a simple click with PayPal information and shipping information pre-saved in a preferences file on the iPhone. We even witnessed a pizza being ordered and paid for with PayPal.

Payments to and from the "Cloud" is a concept likely to succeed because it takes advantage of all of the things that make the Cloud itself advantageous, such as abstraction from the complexities of payment networks,  no software or hardware investments, easy API interfaces, simple adoption procedures, and usage-based expenses rather than capital expenses. And of course, the easier it is for buyers to buy, the greater the chance that they will. There are competitors of course to PayPal, including Amazon with DevPay and Google Payments circling overhead, and not to mention probably hundreds of smaller guys trying to make a living on the buying and selling of others, and it is still an early market so a lot can happen of course.

But I think this new platform and set of APIs with the easy ability for developers to incorporate Paypal as a payment mechanism for a whole new array of payment collection points will be a big win for all of us in the space and everyone seeking new, creative ways to conduct business.

Five Year Milestone

As you can see from the cake below, StrikeIron just had a birthday. It has been five exciting years since we first envisioned the concept of a Web services highway, a worldwide API, the "Earth SDK", the great data cloud, or whatever term you want to use to describe the catalogue of easy-to-integrate Web services and the underlying data distribution and commerce platform that StrikeIron has evolved into today.

When I think about the early days of StrikeIron and a lot of the hard work and sweat that went into the early vision, I always think about the first piece of Web services technology that we built: our Web Services Analyzer product. It is still available as a free download: http://www.strikeiron.com/tools/tools_analyzer_windows.aspx

At that time in 2003 there were very few Web services tools available. So if you actually were lucky enough to come across a rare XML Web service, you would have to generate some code stubs in one of the few IDEs that supported this functionality. Then you would need to write some code (which could take an hour or two) to figure out the behavior of the service and its different operations, especially since any kind of documentaton was limited. We knew this difficulty would result in an impediment to Web services adoption in general, so it was one of the first challenges we tackled.

To drastically reduce the time it took to understand a given Web service's behavior and therefore usefulness, the StrikeIron Web Services Analyzer served essentially as a "universal Web services client", enabling it to be pointed to the WSDL URL of any Web service. "Analyzing" a service provided for its input and output parameters to be graphically represented on a tree structure. Then, all that was required was to simply plug in a couple of values directly to the tree and then "invoking" the service to see what output was generated from various input values. This would make it much easier for client developers to determine how best to put the service to use.

You can imagine the vision of this tool: the expectation that the Service Oriented Architecture (SOA) concept would result in hundreds or thousands of services being created, necessitating a sandbox environment to try them out before they were put to use by an army of developers.

We then of course added all kinds of bells and whistles such as the ability to save parameters for later use, logging, Excel-like output grids, a "favorite services" menu, the ability to view SOAP messages, integration with various service directories such as UDDI and so forth, all of which are still present in the free product still available on our site.

This tool still has a great following and usefulness today (I use it all the time as do many at StrikeIron) to try out and test new Web services (who has time for coding?). This Web Services Analyzer served as the launch pad for what StrikeIron has become. It is a small piece of a much larger service, platform, and data cloud story.

So when I think about StrikeIron's beginnings, the StrikeIron Web Services Analyzer always come to mind. Happy Birthday StrikeIron!

StrikeIron Launches the Developer Community

I am excited about the launch of our Developer Community, a very important part of StrikeIron's vision of the Internet as a medium to transfer data and connect computer systems, devices, Web sites, and people in new and innovative ways. The purpose of our new developer community is to facilitate collaboration for those with a common interest in pushing towards this "hyperconnected" world, and for those sharing a common need for a platform to serve as the mechanism to eliminate the friction in the evolution of this hyperconnected world. We have created a place where these ideas and the application of these ideas can flourish, as well as provide a means and an opportunity for the implementation of these ideas to also be monetized where appropriate by those whose problems are solved by the application of these ideas, as incentive is always an important part of innovation and technology adoption.

StrikeIron is spending its waking hours aggregating data sources (D&B, Gale Group, NASDAQ, Zacks, government data sources) and other functionality (such as SMS, IVR, identity verification logic) into a catalogue of building blocks sharing a consistent interface (for reduced complexity) that live on our platform (where we have invested heavily) and are available to the public for integration into Web sites, applications, devices, and any other place where these building blocks in the form of SOAP & REST Web services can be consumed. Essentially, we have built a publicly accessible Service Oriented Architecture (SOA) and the infrastructure to support it. We call it our "Web Services Marketplace."

The purpose of our developer community is to create an environment that encourages and provides incentive for useful solutions, mashups, widgets, gadgets, situational applications, integrations and other innovations utilizing all of the aggregated data and functional content that we have aggregated as part of our Web services Marketplace, including those that take advantage of StrikeIron's Partner API. We also will promote these solutions contributed by developers within the community as part of our Marketplace. We firmly believe in the importance of integrating community with marketplace as an effective means to drive forward the interests of the community and we know that the way to drive contribution from the community is by providing a means for those contributions to be showcased and rewarded.

And of course we want to go way beyond this by also providing moderated forums to exchange expert advice about Web services and the shared visions of hyperconnectivity, SOA, and frictionless integration. This includes collaboration, asking and answering questions from and with our partners, customers and those simply curious, and providing technical support to anyone and everyone.

We also are building technical libraries of documentation, white papers, blogs, videos, sample source code, and other educational material of interest (and seeking contributions of such). We are listing events of interest worldwide to the members of this community, so if you have any you would like posted, please let us know.

It is still early days of the launch of this exciting and emerging developer community, so look for successive and incremental additions to the community in the months to come and provide us with any and all input and ideas on improving this community as a fertile ground for growing and evolving the hyperconnected world. We have built it for you because we need your help to fulfill the vision of this movement of the hyperconnected world.

The making of The StrikeIron Marketplace

I often get asked about the reason behind the birth of StrikeIron, so I thought it might be a good idea to tell the story. It helps people better understand the value of the company that we are delivering to over 1000 customers today.

As one of the co-founders of a company called DataFlux, I was part of a team that built a company around the concept of data cleansing. This meant that we heuristically standardized data permutations that existed within data tables (for example: "IBM", "International Business Machines", "I.B.M."), eliminated duplicate records ("Bob Smith", "Robert E. Smith"), and made it easier to match data across different data sources when there wasn't a 100% match using these same heuristics. We did all of this through nice graphical user interfaces and utilizing novel database technology available at the time such as ODBC. Ultimately, the company was acquired by SAS Institute while it was growing and still continues to have a successful track record of growth today.

As part of this data cleansing industry at time, we also found ourselves in the business of reference-based address cleansing. This meant taking an address (100 Main St., Anytown, USA), standardizing it to make it easier to match, and then checking the 400 megabyte United States Postal Service master address database to ensure that the address indeed physically existed, the zip code was correct, and any additional known information about that address could be enhanced with a host of other data fields such as county name, congressional district, latitude & longitude coordinates, and more.

As everyone knows, new zip codes and addresses are continuously being added, so in order to maintain the highest possible accuracy rates for address cleansing, we had to ship new CDs every month from the USPS to all of our customers. These data updates then had to be added to the existing implementation, tested, and then moved to production environments. Depending on the customer, this often arduous and potentially error-prone process had to be performed every month, required resources and contributed to I.T. complexity.

Five or so years ago, when XML-based Web services began to emerge, it occurred to me that this technology and the Internet in general had the potential to solve this resource-consuming and somewhat risky address verification process. It was clear that the data updates could be performed at a master data center and then accessed as a function call over the Web whenever ”address verification" was required. No more data updates and all of the associated ongoing complexity!

And then it occurred to the founders of StrikeIron that if it could be done for address verification, then there was a long list of external data sources and external functionality that could utilize the same approach. This of course could reduce all of the resources and cost required to maintain this data in-house, not to mention the accuracy degradation of internally maintained external data.

Today, the original address verification service has evolved into an entire Web-based data and business functionality delivery platform and integratable data catalogue, making this solution a reality for not only address cleansing, but demographic data such as Gale Group Business data, D&B data, financial data from NASDAQ, ZACKS, and other data sources, programmatic access to functions such as SMS, IVR, and email verification (with standardized business models) are now a reality. There are also government sources such as Census data, currency rates, and sales and use tax rates, and of course a whole lot more.

The end-game for StrikeIron is the same now as it was when we released our very first Web service: greatly reduce the cost and complexity associated with integrating external data sources into internal applications, Web sites, mobile devices, third-party software applications, and any other mechanism that has the ability to consume SOAP or REST-based Web services.

We think we are delivering well, but please let us know if you have any good suggestions.

Innovations in Infrastructure--What you Don't See at StrikeIron

StrikeIron has several areas of innovation focus that are highly visible. These include new Web services ranging from live financial and business demographics, to useful business functionality such as text-to-voice and SMS notification services. We have built drag-and-drop universal clients for Web services in Excel. We have done integrations for several third party applications such as Salesforce.com, Microsoft Outlook, various IBM technologies, and many others. We continue to improve upon a sophisticated billing and usage metering engine that enables both our integration partners and data suppliers to receive usage-based compensation in a timely and automated fashion. We also strive to build an interactive and rich user experience for our customers and site visitors. And of course, there is much more innovation to come in each of these areas later this year and beyond.

However, we also spend a lot of time, effort, and resources on our internal infrastructure. First, a shared infrastructure model like StrikeIron's is great for business as it allows infrastructure and uptime monitoring to be shared across tens of thousands of stakeholders. For example, if the power goes out in your subdivision, one of your neighbors might have reported the problem to the electric company and the issue might be resolved before you come home from dinner and even notice. This is one of the nice benefits of a shared infrastructure resource model.

Yet, we don't want to wait until a customer notifies us of a difficulty before we cut into action. We proactively make major investments in redundant servers, load balancing technology, database redundancy, eliminating single points of failure including electrical, and other forms of redundancy and failover to prevent failure and performance degradation. In addition, we have built our own monitoring technology which enables us to check the health of our system and the responsiveness of individual Web services and data sources from multiple points around the globe on a minute-by-minute basis. Should the slightest hint of a problem arise, members of our technical team are alerted in multiple ways, including our own SMS notification services. This enables us to provide immediate response to resolve these issues. Customers that have been with us for awhile know we have a great track record of uptime and rarely have unplanned outages because we invest so much in staying ahead of the infrastructure curve.

So while innovation that you can see often comes with a "wow" factor, we know that the investments and innovation that we put have into our infrastructure both historically and moving forward is a major component of our success as well as our customers' success. Without gaining a reputation for reliability and trust, the rest of it doesn't matter.

New Web Service Authentication Alternatives

Traditionally, StrikeIron has provided Web services that utilize SOAP headers for authentication with a UserID and Password. This is a preferred approach in many scenarios where it is beneficial to separate security from the data payload and is also helpful in creating re-usable classes for developers.

However, lately we have received increasing customer demand for enabling parameter-based authentication as many third-party products do not support the use of SOAP headers, especially many IDEs that generate client code to consume Web services. And of course with some development environments, it's just easier.

In response we enabled authentication via actual data parameters as well as SOAP headers. This can simplify accessing StrikeIron Web services for those who prefer this mechanism.

For example, with our sales tax rates Web service, here is the traditional WSDL using SOAP Headers for authentication:
http://ws.strikeiron.com/TaxDataBasic4?WSDL

and here is the WSDL utilizing parameters for authentication:
http://wsparam.strikeiron.com/TaxDataBasic4?WSDL. The only difference is the domain URL prefix.

The same is true with our free Super Data Pack services. Simply change the WSDL URL prefix from 'sdpws' to 'sdpwsparam', and you're off and running - no more SOAP headers. For more on these authentication methods, visit www.strikeiron.com/authentication.

As always, we will do our best to meet the requests of our customers and partners. Please keep them coming!