First off there is the mental change required, four steps here.
- Focus on how people and especially teams work
- Accept that HTTP isn't a functional API
- Accept that enterprise integration, B2B and Machine to Machine require a new approach
- Accept that the integration technology isn't the thing that delivers value
DEFINE A CONTRACTSeriously its that easy. The reason why WSDL succeeded in the enterprise is that it gave a very simple way of doing just this. The interface contract needs to define a limited number of things
- What is the function being invoked (for REST this could just be a description)
- What data can be passed and will be returned
- How to invoke it (that would be the URI and the method (POST, GET, PUT, DELETE))
- REST remains a niche technology
- REST becomes used in the enterprise
Now in order to become more used we need to also agree things like how you do user authentication, field level security & encryption, rules for reliability on non-idempotent requests, so you know whether your POST request really worked....
So what else does REST need to do? Well it needs to focus on tools because plumbing has zero value. Dynamism does happen but its measured in weeks and months not in days which means an agile release process can handle it perfectly well so all that dynamism and low level coding doesn't really add anything to enterprise development.
This is a key point, something I raised in 2006 (SOA v REST more pointless than vi v emacs) the value is what happens AFTER the call is made, focusing on making the calling "better" is just pointless, the aim is to make the calling as simple as possible.
So basically to succeed REST needs to copy the most successful part of SOAP... the WSDL, sorry folks but an "improved" WSDL based around REST and the associated tooling is required.
Or alternatively the REST crowd could just bury its head in the sand and pretend that its the fault of the enterprise that REST isn't being adopted.
There is no value in integration only in what integration enables.