There is an interesting discussion in the LinkedIn Service Oriented Architecture Special Interest Group, following top contributor Alex Yakimovitch’s question whether REST API service definition frameworks getting more traction means that they are going to be “recognized as one of the SOA implementation models”. My opinion is that such frameworks and other developments in the REST API field are going to make SOA options in the fields of platforms and tools more flexible, and here is my full answer.
In the entreprise, the ability to specify first, and then develop client and server separately according to a specified contract (such as a WSDL service definition) is paramount.
Now, it’s a little bit far-fetched to say that REST APIs don’t have service interfaces. They have some, but sometimes it’s defined in informal documentation rather than in a formal definition, or hardcoded in the server’s way of checking the format of PUT/POSTed Resources.
Actually, WSDL mixes up a lot of different features, as Eric said in first post :
- helping check service messages, for server or client side
- helping generate servers, skeleton or test mocks
- helping generate clients, for testing or for client developers
- protocol and non-functional configuration
- possibly even documentation
WSDL is practical because it provides all-in-one, though coupled support for all these features. But this support is limited, and once the limit has been reached, said coupling prevents any further level of support. For instance, WSDL can check that a field is a string or among a list of values, but not that it should conform to a given regular expression, though it could be a valuable check to single out invalid business messages.
The solution is to decouple all these features. Provide WSDL, but if in your business domain you encounter often message validation problems, think about providing additional validation tools.
In the case of REST API, such tools are precisely decoupled. Sorry to have taken up so many lines to get there, but it’s my main point. it’s up to the API developer to choose which feature and how to use and offer to its clients. For instance,
- Swagger provides web playground, documentation and client generation
- RAML provides documentation, API designer and web playground, server framework, testing using SOAPUI
- SPoRE provides portable client generation when you don’t own the API
- JSON-Schema or RxSchema provide validation, with Schematron being more useful for sparse definitions
Indeed, providing the API is only the start, helping its users use it and get added value out of it now and in the future is the difference between a forgotten and a successful, well-liked API.
Now, obviously, there are other differences between SOAP / WSDL services and REST APIs (such as WSDL being business operation-, transition-oriented, or “RPC”-like as Eric said ; versus REST being state-oriented), but going back to the original question : until there is a REST way to do contract-based SOA development that is as easy as SOAP / WSDL (one-stop format checking, client & server generation, documentation), which is not happening tomorrow because as we’ve seen there’s no single answer, WSDL in not going anywhere. But “traditional” SOA platform and tools will learn from REST flexibility.