One of the features of StrikeIron's IronCloud platform is that it can accept invocations of Web services via multiple protocols including both SOAP and REST. This maximizes the audience of potential users and provides for a good deal of flexibility with multiple IDEs, coding styles, and platform implementations.
In addition to the support for SOAP calls within the platform (including SOAP Headers, SOAP parameter-based authentication, and SOAP w/ HTTP Secure) there is also support for accepting REST calls. This is achieved within the “Transformation” sub-system of our IronCloud platform, meaning we translate the REST call to its equivalent SOAP call before hitting the actual Web service living within our data centers, and then translate the response back to the REST format before it is sent back to the calling entity, and of course all within milliseconds.
This is powerful because it allows any of our services to be integrated into Web scripting languages and other places where a REST call might be more appropriate or convenient, and opens up the functionality to Web developers who can quickly put this concept to use. These REST calls for example can easily be used within PHP, Python, Ruby, ColdFusion, JavaScript, Perl and even embedded into Java, .NET, and other IDE platforms, including anything that can utilize Representational State Transfer (REST). In other words, REST provides a nice interface for easy leveraging of functionality out in the Cloud.
Here is an example using REST with our North American Address Verification service, a Web API that validates the existence of any address in the United States or Canada, and then standardizes the address according to postal standards (as well as appending additional data such as county and latitude/longitude coordinates). The example below can be entered into any Web browser address line as-is (with the appropriate authentication - click the Free Trials button to the right or contact StrikeIron to get access) in order to get a response. You can then change parameter values for different addresses to get the different corresponding responses. You can also try other methods within any of our Web services following the same form (you have to change the parameters to match the method of course).
Form:
http://ws.strikeiron.com/NAAddressVerification6/NorthAmericanAddressVerificationService/NorthAmericanAddressVerification?LicenseInfo.RegisteredUser.UserID=[UserID]&LicenseInfo.RegisteredUser.Password=[Password]&NorthAmericanAddressVerification.AddressLine1=[AddressLine1]&NorthAmericanAddressVerification.AddressLine2=[AddressLine2]&NorthAmericanAddressVerification.CityStateOrProvinceZIPOrPostalCode=[CityStateZip]&NorthAmericanAddressVerification.Country=[Country]&NorthAmericanAddressVerification.Casing=[Casing]
Example:
http://ws.strikeiron.com/NAAddressVerification6/NorthAmericanAddressVerificationService/NorthAmericanAddressVerification?LicenseInfo.RegisteredUser.UserID=***********&LicenseInfo.RegisteredUser.Password=******&NorthAmericanAddressVerification.AddressLine1=15501 Weston Parkway&NorthAmericanAddressVerification.AddressLine2=&NorthAmericanAddressVerification.CityStateOrProvinceZIPOrPostalCode=Cary NC&NorthAmericanAddressVerification.Country=US&NorthAmericanAddressVerification.Casing=UPPER
Because a REST call contains parameters including UserID and Password, we of course recommend to our users that these parameters be stored in a non-viewable config file and not the actual Web page source, or some other means of hiding credentials (within non-viewable code or within a database for example).
Have a REST-related question? Contact us at support@strikeiron.com Like a free trial? Contact us at info@strikeiron.com
