Authentication and Protocol Alternatives When Consuming StrikeIron Web Services
Posted by Bob Brauer on Wed, Jan 18, 2012
Over the years, we have learned that providing flexibility within our Cloud-based data delivery platform helps better serve (and therefore expand) our customer base. In order to support the broadest number of coding styles, Cloud environments, IDEs, and other software development tools, we have provided multiple ways to invoke our various Web services APIs. This includes use of multiple protocols, as well as multiple ways to utilize each protocol.
For example, when using the SOAP protocol to invoke a StrikeIron Web service, you have the option of passing authentication parameters (your UserID and Password) either within SOAP headers, or as parameters as part of the service data payload.
Some developers prefer SOAP headers because it allows them to create reusable authentication code that can be leveraged with multiple StrikeIron services (all StrikeIron services share the same interface, authentication mechanisms, service behavior, and response codes). However, many IDEs do not support SOAP headers, so sending authentication by parameter, along with the rest of the data payload, is the only option in some cases.
Depending on the authentication method utilized, there is a different service endpoint required. The primary difference (other than the service call structure inside the XML, transparent in most cases) is the domain prefix. With North American Address Verification for example, the SOAP Header endpoint is:
http://ws.strikeiron.com/NAAddressVerification6?WSDL
If you want to pass the UserID and Password via actual parameters to the service, in that case the endpoint is as follows (note "wsparam" versus "ws"):
http://wsparam.strikeiron.com/NAAddressVerification6?WSDL
We also provide the ability to invoke our services using the REST protocol. Sometimes this is preferred, especially when services are being built into Websites using PHP, Ajax, and other other scripting technologies. Here is an example of our Email Verification service using a REST call (if you have a StrikeIron UserID and Password, you can paste this code into a Web browser to invoke it):
http://ws.strikeiron.com/StrikeIron/EmailVerify5/EmailVerification/VerifyEmail?LicenseInfo.RegisteredUser.UserID=[UserID]&LicenseInfo.RegisteredUser.Password=[Password]&VerifyEmail.Email=[EmailAddress]&VerifyEmail.Timeout=[TimeoutValue]
Finally, if you prefer to securely transmit the data of a Web service invocation, you can simply replace "HTTP" in the service endpoint with "HTTPS" in the URL. This will encrypt the data appropriately as it travels from your application or Website to the StrikeIron platform and data centers, and then back again to your application or Website.
https://ws.strikeiron.com/StrikeIron/EmailVerify5/EmailVerification/VerifyEmail?LicenseInfo.RegisteredUser.UserID=[UserID]&LicenseInfo.RegisteredUser.Password=[Password]&VerifyEmail.Email=[EmailAddress]&VerifyEmail.Timeout=[TimeoutValue]
These authentication and invoking protocol preferences have been in largest demand by our customer base to date, resulting in their various implementations. If you have other protocols or authentication mechanisms you would like to see us support and build into our delivery platform, please let us know in the comments below.