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.
And remember:
There is no value in integration only in what integration enables.
Technorati Tags: SOA, Service Architecture
27 comments:
What your describing is problems with using HTTP as a RPC mechanism, not REST.
REST already has contracts in the form of hypermedia. A media type defines everything needed for a contract and can be validated against a DTD/XSD/RelaxNG (if using XML) or whatever the equivalent would be for other data formats.
The last thing REST needs is WSDL. WSDL is arguably the worst aspect of working with SOAP services. All WSDL does is make it easy to create brittle client proxies that hide the fact your working with a distributed system.h
Scott,
Hypermedia are not functional contracts and its not standardised.
Lets put it this way:
Give me a REST definition for the submission of an invoice and its payment....
Steve
Steve,
You define a new media type like application/vnd.payment+xml. It's no different than what you're doing with SOAP+WSDL.
Unless you're using something like cXML or ebXML for all of your WSDL contracts, then your SOAP services aren't standardized either...
Scott,
Seriously, yes that gives you the data exchange, but what tells you how to create an invoice (is it PUT or POST?), what tells you how to PAY that invoice? and how do I publish that information to someone so they can write their side of the application without having to wait for me to deploy into production?
MIME defines the data, not the function, businesses are about the function.
Functional contracts lead to behavioral coupling which limits the evolvability of your service. Most enterprise architects are familiar with the use of events to reduce behavioral coupling; it's also well-known that event driven interfaces often have scalability issues because events are often being spewed across the network just in case someone cares about them.
Hypermedia is an event filter
You get the decoupling of an event driven architecture without the scale impact.
In REST you don't have a contract for the service, because the client is instead exposing an interface to the server. Hypermedia adapts the client's interface to the server's -- Hypermedia is a mediator.
Wonderful words but it misses the actual point....
If that was actually true and made it easier to deliver enterprise systems then people would be doing it.
It doesn't, so they don't.
Except when they do...
VoiceXML browsers are all over the enterprise for example.
VoiceXML dates back to 1999 IIRC, I certainly remember the voice folks I worked with using it around 2001.
Not a REST success, that is an XML over HTTP success.
VoiceXML 3.0 doesn't even mention REST and defines, very clearly, its functional interfaces in terms of "prompt" et al in the tags.
Not sure how that counts as a REST success story in the enterprise, that is even before we just reduce VoiceXML to HTML for Voice Browsers.
I think you white-wash both enterprises and REST in this post. As an interesting counterpoint, you should see Jon Moore's presentation from last year's Oredev, Hypermedia APIs. Protocols are contracts, if you bother to understand them.
That is part of my point.
The REST argument is that people aren't spending enough time learning REST and if they did it would all be fine (despite the fact that no two REST implementations implement these approaches consistently).
Its been six years, maybe the REST community needs to make a bit more effort in being consistent and clear.
Seriously, which action to use is spelled out fairly clearly under the uniform interface constraint. In the case of HTTP, it clearly states that POST would be used to create an invoice.
The primary reason REST isn't used in enterprise is the glacial pace that Big Enterprisey Vendors take to adopting technology. They've all invested heavily in SOAP and will continue to flog it until it starts losing them customers.
On the first point. Why is it not PUT and what would the URI be?
On the second, that just isn't true. SOAP went from zero vendors to near total support in 2 years and total adoption in 4, because people could see the value in standardised integration over previous approaches.
Its a myth to say that enterprise IT vendors don't evolve quickly, they have to in order to sell new products and they sell what people are buying, and people buy what they feel will work best.
Very few people appear to be asking for REST in the real world rather than the blog & hype spheres.
On the first point, because PUT is for updates, not creates. Again, this is spelled out as part of the uniform interface constraint. The URI would be arbitrary, the same way it would be for a SOAP endpoint.
On the second point, the same enterprise vendors who "quickly" adopted SOAP were the same ones who created and standardized it. Whether or not REST is superior is irrelevant as those same vendors are more interested in protecting their (substantial) investment in SOAP.
Enterprise customers aren't choosing REST because they generally take whatever solution their vendor of choice happens to be shoveling. Since they're all shoveling SOAP, it isn't a stretch to see enterprise customers are using SOAP.
By your logic, we should have abandoned WSDL years ago. It's been around for over a decade and it's anything but clear. It still lacks any form of versioning and the vendor tooling you're so fond of has reduced it to another object IDL.
LOL this is a hilarious post.
Um...
REST *is* used in the enterprise. We use it in software that we sell to customers from the largest on the planet (governments, fortune 500), to the smallest (SMBs, etc), and everyone in between. In fact, when we tell folks that we have standardized on using REST for our APIs they nod their heads and applaud our decision. It *helps* drive sales of this mission critical software.
REST works. It's simple. And... it is very "enterprise".
Thanks for these series of posts on the success/failure of REST in the enterprise Steve. Regardless of the REST fanboys and the outlying enterprise users who do make of REST in the enterprise, as you say mostly it's failed in adoption amongst enterprises and the vendors. I think trying to articulate this point constructively is an important one, and the reason I've enjoyed your blog posts.
Keep up the good work.
CM.
Scott, I was under the impression that PUT could be used to create new instances as long as the creation was idempotent.
The reason the enterprise vendors went to SOAP was that customers PUSHED them to it. They all liked their proprietary lock-in integration approaches but clients didn't. Enterprise customers aren't the sheep you try and portray them as.
On the lack of tooling and versioning support I'm really confused as there are legion of products out there that do both tooling, versioning and release management for WSDLs. I do agree that there has been very little innovation in this area in the last six years.
Anonymous, that is great that enterprise customers are using it. A couple of really nice case studies would help me understand how they are doing that.
Previous comment removed for follow-ups...
Steve,
To your last comment regarding tooling--especially versioning. There's a reason why there has been no traction in the last 6+ years; there is no coherent approach.
SOAP's initial specs missed the boat, attempting to coerce it into a new RPC mechanism--thank one of your top 4 for that. WSDL was a knee-jerk to account for those short-comings, and became the worst of all the big vendors invested interests. WS-* became a pie in the sky to re-purpose much of what was already contained in existing protocols like HTTP and (S)MIME.
REST has WADL--which gives you your contract your looking for. It definitely is incomplete, but is one approach. In general the typical REST 'groupie' prefers their contract to be delivered using a known tool -- the browser.
IMHO you're too invested in the WS-* realm to realize that these technologies are not all that unlike. There is nothing preventing me from creating a REST service that consumes and produces SOAP documents...which actually process SOAP headers! Would that REST service then be considered SOAP service capable of consuming all of the WS-* extensions?
JustGettingBy
I really don't care whether its REST or WS-*, genuinely, I don't think that its actually important as the real value is in the invocation, not in the mechanism.
The reality is that WSDL, though not "technically" perfect, works for PEOPLE. REST might be "technically" better but clearly its not working as well for people.
I don't care whether we use REST, WS-*, flying monkeys or binary encoded mud... as long as its good enough and it works for PEOPLE.
Re: solving practical problems, there is an important business issue that neither SOA nor REST resolve - both lack practical means to provide a 'shared understanding' (context) with the client that doesn't in some way violate their core tenets. How do we increase flexibility of client while supporting governance?
Dynamically generating Service interface violates encapsulation and is expensive if not completely impractical (simply persisting interaction context is not the same as managing all cross-cutting concerns at run-time).
Creating a shared understanding with the Server couples client and server in a way that undermines REST (good luck with universal standards for Media Types - REST itself isn't a standard).
I agree with Steve's premise, but I'd suggest what Resource-Orientation needs (not REST as that's immutable dogma) is not interfaces like WADL, but protocols. An interface would kill the latent transformational power of Resources. Resource-Orientation lends itself to declarative protocol-driven choreography (albeit Server-mediated with out-of-band context).
We've used this approach to create rich enterprise apps that are situationally-aware. Lightweight, scalable, auditable, secure and practical...
@Steve
One question on the contract aspect, what additional information would you need on top of the sort of content in (for example) RFC 5023?
I highly recommend that you read the O'Reilly publication "REST in Practice" and also consider the somewhat older "RESTful WebServices" book as well.
Yes, we have to remember that the HTTP protocol was developed many, many years ago to move hypertext documents around.
It has been b*stardised and beaten to do many other things over the years, on the whole very successfully.
But the point is, it was never designed to do what it does today so we have to expect many problems and limitations.
I think you make some good points here.
1. Focus on how people and especially teams work
2. Focus on tools
And I would add a third
3. Make education and training more accessible
In response to WSDL/WADL and the necessity of service contracts I would ask you :
Is the HTML specification not a sufficient contract to allow for the adoption of single entry point web-based intranet applications such as CRMs?
Then would a similar machine-to-machine hypermedia specification paired with a single entry point really be so different?
I believe that hypermedia descriptions can prove adequate contracts if people are able to see their m2m code as just another type of user agent talking over HTTP to a remote server.
And I think you're right, hypermedia specification formats have a long way to go before they will enjoy the level of reception available to widely accepted service contract formats such as WSDL.
Ken, in theory Hypermedia/MIME could be used for M2M but in reality it isn't because there isn't the formalism.
People are great a dealing with similar things and linking them, computers are rubbish and need things proscribed.
REST is increasing in use in the enterprise. We (a multi $B logistics companY) just built an order management system that manages over $1b of orders. Its service interface is JSON and HTTP.
Do we have a contract? Yes. It's written as a wiki document and alternative Word document. It looks quite similar to the same sort of document one writes to support WDSL, since you don't actually document how the interface *works* in a WSDL, you just apply enough so the tools can do some fancy code generation. It's a contract in the same sense that a boilerplate of section headings is a contract. The only difference with our approach is that we don't rely on code generation and large vendor tools that require tremendous learning curves to operate in a performing, available manner.
Would the Web-in-the-enterprise benefit from a richer contract MIME type for describing writes on the web? Yes, and this was the topic of my keynote at the WS-REST workshop in March. We have interfaces that are going to be a lot more complex as we adopt more RESTful services. Working on it. Not my #1 priority unfortunately (shipping projects is higher).
The long and short of it is that WSDL has never worked for people - the contract is always something that has to go beyond the WSDL. RESTful web services lack a machine readable contract for enterprise integration use cases but is doing quite well outside. Steve, the one thing I learned being outside the enterprise for 3 years is that it no longer is the "real world" - it's just one of several worlds. There is a lot more IT going on outside of the enterprise, with newer technologies that "enterprises" would never would touch, than one can imagine. There's a different value system at play in technology-first companies, that's all. I think there's opportunity to learn from both but clearly the innovation is in the consumer space right now , IMO.
Post a Comment