Why we use SOAP...
- BWS was not designed for end-user consumption.
- Therefore, it's about server to server communication.
- REST is more about client to server resource access.
- SOAP offers more security and higher (and checkable) code correctness confidence.
- REST cacheability argument not applicable here.
- SOAP size overhead negligible when looking at the payload size (especially images).
Strict separation of biometric data and personal information like user names and passwords are a fundamental part of the design of the BioID Web Service. All data, e.g. the biometric template and trait samples (images, voice recordings) is identified by a Biometric Class ID (BCID). While this BCID is unique within the BWS instance used for storing and processing the biometric data, it is complete anonymous and not connected to any personal information.
The matching of a BCID identifier to personal information of an enrolled BWS user has to be done externally by the customers. The architecture of our service was intentionally designed this way so that no user information can be associated with a specific BioID Class ID by a third party—not even us.
Thus BioID Web Service was not designed for consumption by end-users or client systems and devices. Instead, a trusted intermediate system handling the user management is required.
The Nature of BWS Communication
For the communication between the customer's infrastructure and the BioID Web Service the SOAP protocol is used as a reliable structured protocol for data exchange. One advantage of using SOAP with common HTTP(S) as transport is the ease of tunneling the protocol over proxies or firewalls although SOAP offers more possibilities than using HTTP as transport protocol with TLS/SSL as security option.
Most of the network traffic created by biometric systems consists of media data payloads so it is important to implement technologies which guarantee an efficient and secure transport. While RESTful web services are very popular for client to server communications the scenario of the BWS is a server to server communication.
The SOAP interface description is provided as a structured template compiled in the Web Services Description Language (WSDL) by BioID. The WSDL allows for automatic discovery of service methods by development tools and compilation of the needed client libraries.
One argument for RESTful services is often the cacheability of REST reads compared to uncacheable SOAP reads. In the typical scenario of BWS API calls and responses there is little to no cacheable content so this argument does not apply here. Also the advantage of ostensibly lightweight RESTful services with JSON compared to SOAP and XML vanishes if one looks at the binary data payload encapsulated in the API calls and responses.
An online shop dealing with shopping cart data sets or product numbers benefits highly from a RESTful apporach. But for BWS it's mostly about image and voice data being sent to and from the BWS in a single API call. This is easier to embedd in the XML of a SOAP call than in a still-to-be-specified encoding within a REST body.
The API methods defined by the service contract in WSDL can be created automatically by modern development tools. This greatly reduces the probability of errors being introduced by manually coding against the API definitions. Moreover, the comprehensive and concise web service API definition reduces the time needed for testing and quality assurance.
Development toolkits that automatically process the service contract description help mastering the implementation of robust and accurate access to foreign resources. RESTful services tolerate more sloppy implementations which may be robust with respect to small API data definition changes. SOAP on the other hand provides strong typing and requires a strict interface definition but also ensures that there is no ambiguity in data processing. This may an initial impact on rapid prototyping approaches but rewards the developer with a well defined and reliable interface to the service.
Also, in contrast to REST, SOAP allows for the extension of services with standard WS-* web service specifications like WS-Security. To extend REST with similar features is much more vague and needs a lot of negotiation.
RESTful services are focusing on accessing resources while SOAP focuses on accessing operations. While the rise of RESTful services is not surprising in today's browser or mobile application scenarios, it should not be considered a silver bullet to solve also unrelated problems like server to server communication as with the BioID Web Service.
The capabilities SOAP provides with regard to security, reliability and transaction have led us to choose SOAP for our server to server communication. But of course we carefully observe the progress and evolution of other technologies which may be useful for our BWS. If in need, our modular architecture enables us to extend the BWS with other methods should there be high demand and given it is technological reasonable.
So for the time being we think it is the right thing to use SOAP for the consumption of the service.