Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Dilip Krishnan on Sep 02, 2009
Justin Cormack sparks a discussion about the adoption of RESTful architectures in the enterprise or the lack thereof with his post.
… there was a minute where the CTO said (more or less) “does anyone know of any let or hindrance to this being a SOAP API?”. Like those moments at weddings, no one spoke out. But I do object. SOAP is not the backbone of a happy architecture, but we do not have the strength to say no right now.
As he explains the role of resources in the enterprise, he points to the statistic that 9 out of 20 [developers] prefer to use REST [as] it is more productive. He alludes to the simplicity of using a REST based API as opposed to generating proxies from service contracts and schemas (wsdl, xsd) of services, which may or may not be built on WS-* standards.
It does not involve programs to generate huge chunks of useless code. It involves hypertext (HATEOS) not opaque documents that are mappings of database schemas.
He continues to explain the idea of resources in the enterprise with an example of how one might model a typical customer in a CRM system.
What are the resources in the enterprise? Start with customers. A CRM system is a clear example of something that needs to be modeled as resources. You need API calls that can find products a customer has bought, support tickets, all the core data that you would need to build customer service portals, internal support applications.
According to this article, which talks about ROE (Resource oriented enterprise), every enterprise has silos of data; silos that satisfy different business functions, payroll, HR etc. and there are benefits to thinking of the data these silos represent, as addressable resources. Benefits in terms of cost as well as opening up these islands of data than can then be used to drive informed business decisions.
… what the ROE asks for, they must further open themselves. Not primarily in a technical sense, but by offering better abstractions of their information content. In the Resource Oriented Enterprise, this is clearly achieved by integrating them into the URI-based addressing scheme.
According to Justin, its not hard to do this.
Building this framework can be incremental. You need either tools that already provide REST APIs, which is becoming easier, or a web application development framework. This is the convergence point between application frameworks and web content management.
In addition to the benefits of moving towards an ROE he mentions in his post, he also aggregates some of the responses from the REST mailing list.
[it] makes things human browsable, and declarative makes them computer browsable […] Business logic becomes content rather than data, rather than there being tables of parameters that the business logic black box feeds off, the states themselves become resources that can be discovered, addressed, and reasoned with.
Introducing REST to the enterprise […] help[s] the enterprise leverage the agility of the web architecture, and to make building new enterprise applications cheaper and easier.
the use of REST brings the decentralization aspects of the Web into the enterprise world and allows designers and developers of networked systems to create and evolve their components without the resource and time consuming effort of bringing them into a single room to discuss APIs. [Jan Algermissen from the rest-discuss mailing list]
I believe that REST’s use of hypermedia […] make maintenance, deployment and versioning much easier, which translates to lower costs to the business in the maintenance phase of an application. [Darrel Miller from the rest-discuss mailing list]
Also, […]interoperability is much easier to achieve with REST because the ubiquity of HTTP. This has a huge positive side-effect for integration as well. My gut tells me that SOA Governance could really reap the benefits of a RESTful architecture as well, but I don’t have any details yet on how. [Bill Burke from the rest-discuss mailing list]
Justin highlights Benjamin Carlyle’s observation that you can view REST as an evolution of SOA, as better and easier to consume services. Are we seeing a shift in the emphasis from service orientation towards adoption of RESTful approaches in the enterprise? or is this a natural evolution like Benjamin suggests?
Free $40 SOA Demystified Book Offer
Right Collaboration Architecture Drives Business Transformation
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Restful BPM, Pragmatic SOA, Mashups, Avoiding Failure: SOA track @ QCon London in March
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
Hum.. there is nothing to version in REST, so that makes versioning really easy I guess. Can someone point me to how you do versioning in REST? (hint using a date (/2009/09/03 baked in the URI syntax is not the answer)I believe that REST’s use of hypermedia […] make maintenance, deployment and versioning much easier
REST may be ok for read-only type use. Updates is a different story.
Businesses have many complex rules (these range from the whims of business users to hard legal requirements) which requires maintaining consistency across various elements of data.
This would be hard to do with REST where data is exposed as more or less independent resources.
The general web use does not see this level of complexity.
Businesses still like to think in terms of business transactions.
Where I work, we see REST mostly for read-only, browser-consumed services. Most app-to-app scenarios use WSDL based services.
The whole article is strange, but this sentence is my favourite:
"Also, […]interoperability is much easier to achieve with REST because the ubiquity of HTTP. This has a huge positive side-effect for integration as well."
We do not live in 1990, when there was problem with technical interoperability. What we really need to achieve enterprise interoperability are explicit contracts (it is what WS standards try to achieve, but of course we need much more) with explicit and shared semantics.
Easy (and correct) consuming of services/API and their governance are more important than easy programming. Statistics "9 out of 20 [developers] prefer to use REST" are totally irrelevant. We could argue with statistics that "15 out of 20 programmers do not want to write documentation" (I do not know if there is such statistics :))...
REST is great style, but it tries to solve totally different problems, which are really not so important for ENTERPRISE integration.
JJ, I dont agree that there is nothing to version, services will always evolve, REST or otherwise. So, unless you're implying that RESTful services tend to be perfect :-) (not true either!), the REST versioning problem can be solved fairly easily using a combination of a clever use of media types and content negotiation.
You're right that having dates/versions in the uri are definitely not the answer. Versions are a 'representations' of the resource and if they are not treated as such, it defeats the purpose of having the notion of an addressable resource. Its akin to having /customer/01/xml for an xml 'version' of the payload and /customer/01/json for a JSON 'version' of the payload, not ideal in my opinion.
Peter Williams has nice articles on some approaches.
Peter,
We do not live in 1990, when there was problem with technical interoperability. What we really need to achieve enterprise interoperability are explicit contracts (it is what WS standards try to achieve, but of course we need much more) with explicit and shared semantics.
Very true, but the advantage of a RESTful style (if its done right) is that it allows for unexpected/ unanticipated/ unplanned/ serendipitous integration. Getting 10 people in a room and having them agree on explicit contracts and shared semantics can be quite challenging. Statistics "9 out of 20 [developers] prefer to use REST" are totally irrelevant. We could argue with statistics that "15 out of 20 programmers do not want to write documentation" (I do not know if there is such statistics :))...
:-))REST is great style, but it tries to solve totally different problems
REST is not a good fit for all problems. IMHO, what Justins post is trying to say is that, it is ALSO an option and that it should be more relevant in the enterprise.
There is nothing stopping anyone implementing complex business rules on updates with a REST style interface. There is absolutely no necessity to directly represent data as services, you are merely providing and accepting representations of that data. What you do with the desired representation on an update is totally up to the implementer.
It may require you to think a little differently, but there is nothing stopping you providing a completely reliable (and even indempotent) interface using the REST style. I know because I have seen it done :)
I think most everything can be 'made to work' but how far are we moving away from REST principles?
REST should remain simple and used where its a natural fit - mostly read-only, browser-consumed, resource-oriented services.
Guarding for browser double posts, etc., starts to undermine the original intent and adds complexity which may be better dealt with in other ways.
Also, efforts such as WADL and two-phase commit with REST-HTTP are misguided. We already have WS* for that. And REST principles can be applied with WS* protocols, if needed.
The complexity of advanced WS* is not gratutious - its what business needs.
Most things start simple but then get complex as underlying issues that were glossed over begin to surface. Abandoning WS* to repeat the cycle with plain HTTP (with or with REST) is not worthwhile.
Not to start another REST vs. SOAP debate...
I think most everything can be 'made to work' but how far are we moving away from REST principles?
Like Pete said, I'd say you can do a lot without compromising on any of the principles. Why? because inherently as an architectural style, REST imposes very few 'principles'.
REST should remain simple and used where its a natural fit - mostly read-only, browser-consumed, resource-oriented services.
I would encourage you to check out Jim Webber, Savas Parastatidis & Ian Robinson's article.
Dilip,
1) I agree with you, that there are domains, where REST could be appropriate in enterprise... Probably not for implementation of processes in core process areas (as ordering, billing, assurance...), but it can be good for distributed management of experience/skills/CVs/knowledge management/project portfolio management, where REST principles would help (e.g. as you said - in unexpected integration)...
2) But it is really strange, when REST fans want to take SOA terminology and replace "service" with "resource" to create new buzzwords. It leads to meaningless terms as "Resource oriented enterprise". Problem is that there are 2 SOA, but only 1 REST :)
2.A) There is business-led SOA (which is related to overall business architecture) and developer-led SOA (which is architectural style of design, implementation and overall governance of IT components).
2.B) But there is no business-led REST, there is only developer-led REST. REST fans should replace(soaTerm, 'service', 'resource') only in developer-led SOA terminology. There is really nothing like "Resource oriented enterprise".
Dilip
If you are saying that"Versions are a 'representations' of the resource and if they are not treated as such, it defeats the purpose of having the notion of an addressable resource." are you saying that different versions are different resources? If this is the case you are really suggesting encoding version into URI to distinquish resources
Dilip,
With all do respect, this is such a bad answer. If I am processing payload "by hands", I can do it either with WS or REST, I can deal unexpected/ unanticipated/ unplanned/ serendipitous data. If I am using generated marshalling, whether WS or REST, I have to rely on XSD. This train of arguments is completely flaud.
Hmmm... may be I was not clear, let me try again.If I am processing payload "by hands", I can do it either with WS or REST, I can deal unexpected/ unanticipated/ unplanned/ serendipitous data.
Yr right that WS or REST either client can handle payloads "by hand" but its not so much the "by hands" payload processing, as it is the properties of a RESTful service.
Well designed RESTful services have a unique property; that makes serendipitous re-purposing of data so much easier; the uniform interface. Clients for RESTful services dont need to know explicit service semantics any more, for e.g. transfer money "operation" in a Bank account "service". They only need to deal with resource uris and in most common cases, one of four http methods GET, PUT, POST, DELETE. The canonical example of the success of this style is the google mapping mashups.
One metaphor that really helps me understand this, is accessing data in a database via stored procedures vs. select statements. The rigidity of stored procedure "contracts" prevents client driven "exploration" and repurposing of data.
Hopefully that clarifies the point I was trying to make.
Dilip
are you saying that different versions are different resources?
NoIf this is the case you are really suggesting encoding version into URI to distinquish resources
I think we're in agreement with JJ, that this is a bad idea!
Hi Peter,
Interesting distinction "resource orientated versus service orientated" enterprises. I agree that the business tends to think in terms of functions or "services", but very often these services are loosely defined. Unfortunately software services need to be precisely defined and this is the dilemma. Software services are inherently brittle.
I struggled with REST for a long while too. For me I think the thing that makes the mental shift worth while is the fact that REST is built on messages and late binding. So a restful resource is not fixed unlike a RPC style service. The URI of the resource is fixed, but the media itself (information content and additional links) are free to change (think extend).
This means that if you choose to express your service as a resource then your service becomes immediately more malleable. This malleability is important because it allows your service to be loosely defined. Like someone has said, to get desperate clients to agree on a precise service contract that meets all there needs is a tall order.
Most organisations run on information. Some department needs some information from another department, say an answer to a question. The answer itself is a resource, available from a well defined source. If you think of resources in this way, it is quite easy to see how you can model a service as a set of resources. A resource doesn't need to be static, it just needs to be available when requested.
I think that rest suffers from the same problem object orientation does. It needs a mental shift. So instead of thinking about process you need to think about things, resources. As we get better at doing this, I'm sure that REST will be applied more widely. Late binding is just more flexible and hence more durable. The world-wide-web wouldn't be the success it is today if it was early-bound, static and brittle.
Infact the early binding that exists in the web has held it back. Think HTML/CSS incompatibilities. If your browser doesn't obey the precise service contract then the HTML/CSS feature doesn't work for you. Knowadays, these browser contracts are being relied on to do less and more is being done using late bound executable resources (Javascript) writing to a plain canvas, again a much more flexible model.
It will be interesting to see how far the RESTful paradigm can be pushed. But if I were to hazard a guess, I would say that REST can be push much further then most people think.
Paul.
Yep, it's not moving away from REST principles at all. It's just resources and you can manipulate them anyway you like.
It's not really guarding for double posts but the unreliability of HTTP, which SOAP services would share. How is that handled in the Big Web Services world?
Have to disagree about WS* standards. The basic services may be what is occasionally required, but the way they are implemented is way too much in the complexity stakes.
Well designed RESTful services have a unique property; that makes serendipitous re-purposing of data so much easier; the uniform interface. Clients for RESTful services dont need to know explicit service semantics any more, for e.g. transfer money "operation" in a Bank account "service". They only need to deal with resource uris and in most common cases, one of four http methods GET, PUT, POST, DELETE.
Well, this is another misconception often mentioned by REST proponents. First, not explicitely defining semantic is bad. Second, methods multiplicity is not a WS requirement. I have seen systems implemented using "DoWork" method (take a look at JBoss ESB) and pushing semantics into the message content.
So whats the solution?
I think that rest suffers from the same problem object orientation does. It needs a mental shift. So instead of thinking about process you need to think about things, resources
Oh, but the problem is we never learned to think in processes. We think in applications, which is not the same thing.
Hello
First, let's define the concept of "Version". From Dilip's example, XML and JSON, it seems the version is actually the type of the representation of the resource. For that case, remember that the resource is just one, you can access it using one or more URLs, and you can get one or more representations of it.
So, in that case, the URL of the resource should be the same, and the type of the representation you want to receive should be requested in the content type header of HTTP (in the HTTP context of REST).
Now, if the version concept you mention is the one of a past entity variation, then we are not talking about representations. The entity suffered changes, so if that entity is a resource, the URL points to the latest variation. If you need to keep track of the past variations or states, you need to make a copy of them into a container. Each of those copies is actually a new resource, and thus it needs a different URL. As simple as that.
Now, can someone explain to me why dates and version numbers are not proper in URL? If they work on par with the application semantics, I see no problem that dates are used to identify containers, path or even query data in the URL.
William Martinez Pomares
Architect's Thoughts
Hello.
I have to disagree with several things here.
1. How says that REST should be easy? Maybe it is taken from the original blog that explained an interaction and that all people thought as the REST way? REST is an architectural style for networked, distributed applications. The constrains are to help with several issues from networking, and those are not easy nor simple. So, if you think that REST is just forming URLs on the fly, think again. If you have a simple client-server app, several clients and one server, then REST may not be for you.
2. Who says REST is about exposing data? There are people that not only data, but the complete domain model is exposed, mapping entities to resources. Other map data to resources and map the HTTP operations into CRUD operations. REST is about resources, their states, their representations, and networking constrains. Any other mapping will bring impedance mismatch to the mix.
3. Who says WS* are complex? I think a standard way of doing things is easier than a chaos with no direction, many people doing what they think, and the creator of REST saying those ideas are not REST at all! Complexity of WS* implementations are due to ill-constructed tools that went out to offer what developers wanted due to ill-understood technologies. The services mind shift was not performed, and golden hammer syndrome hit the developers who still think a service is an RPC.
4. What do you need REST for? DO you have a networked application and the you need an architecture style to make it good? Or do you have another type of architecture (SOA or components oriented, maybe a silo) and you need to create an API for the web so you aim for a RESTful API? They are very different things, you know. So few people doing the first one, and so many trying to do the second one, just to claim it in their web site!
So, REST is totally suited for enterprise, where the application is a networked, distributed one. And REST is useful for creating the application architecture, not to create an API. And REST is not a replacement for WS*, they are very different things. And REST is NOT EASY.
William Martinez Pomares
Architect's Thoughts
Peter Rajsky wrote: there are domains, where REST could be appropriate in enterprise... Probably not for implementation of processes in core process areas (as ordering, billing, assurance...), but it can be good for distributed management of experience/skills/CVs/knowledge management/project portfolio management, where REST principles would help (e.g. as you said - in unexpected integration)...
+1, Peter. REST is not for all things, and actually it is for development of applications, not for APIs.
Paul Beckford wrote:
I think that rest suffers from the same problem object orientation does. It needs a mental shift.
Paul! Nice to talk to you again. +1 too.
Resources are different. As I mention in another post in this discussion. Javascript is implied in REST, BTW.
Also, Services were meant to be a definition of what, given a simple how: a unique interface and message passing. The what is the service contract, that was always defined as business functionality. So, where did the IT service contract and RPC bounding came from? I guess because Maslow's law about the hammers :D
When I hear the term: REST services, I get confused. Is it services in a network, or services seen as resources? Then I see the sample and I find URIs with methods and parameters. That is, RPC in the URL. Not RESTful at all. And not services at all.
If you get your service seen as a resource, it means the service will be just one, with one or more representations, and totally driven by message content. I mentioned some example of this in another discussion. I'm even valiant to say that services as resources may be the way to go in some cases.
Cheers!
William Martinez Pomares
Architect's Thoughts
Well, this is another misconception often mentioned by REST proponents. First, not explicitely defining semantic is bad. Second, methods multiplicity is not a WS requirement. I have seen systems implemented using "DoWork" method (take a look at JBoss ESB) and pushing semantics into the message content.
Boris, totally agree with you.
Architect's Thoughts
Thought I already mentioned this...Peter Williams has nice articles on some approaches.
... by using custom media types and content negotiation. That way a client would not need to keep track of different uri's for different 'representations', in shape or form. Where shape = changes in the shape of the entity, e.g. new properties etc, (the entity versioning problem); and form = the format of the representation xml, json etc.
Now, granted that, this is more involved than just slapping a bunch of media types for different versions. The service side of things certainly becomes more complicated, even so, the solution is very desirable because of the network effects as a result of simplicity of the client side.
Now, can someone explain to me why dates and version numbers are not proper in URL? If they work on par with the application semantics, I see no problem that dates are used to identify containers, path or even query data in the URL.
Not looking at it with a RESTful eye, IMHO, its not that its not proper, it may not be a solution that scales (scale as in maintainability over time), if one is not too careful we could end up with a proliferation of endpoints that cannot easily be governed. Secondly, I think whats happening really when one does this, is that, the client assumes the responsibility of routing (making a request to the right url) as opposed to letting the service decide. I think this increases the out-of-band communication that needs to happen between the service providers and clients.
... by using custom media types and content negotiation. That way a client would not need to keep track of different uri's for different 'representations', in shape or form. Where shape = changes in the shape of the entity, e.g. new properties etc, (the entity versioning problem); and form = the format of the representation xml, json etc.
Totally agree. Same I said, just concise.
William Martinez Pomares
Architect's Thoughts
Not looking at it with a RESTful eye, IMHO, its not that its not proper, it may not be a solution that scales (scale as in maintainability over time), if one is not too careful we could end up with a proliferation of endpoints that cannot easily be governed.
Granted. In this case we are assuming the URLs may live there forever. But when returning a URL as a result of a query or a report generation, I see no problem of using that, same if we use a serial number for all resources. You won't expect users to learn all the numbers to get a resource. Secondly, I think whats happening really when one does this, is that, the client assumes the responsibility of routing (making a request to the right url) as opposed to letting the service decide. I think this increases the out-of-band communication that needs to happen between the service providers and clients.
Not really. As mentioned above, you can use the date for a query (I need the state report generates last month) or as a path (the month is part of the path). In that second case, the URL should not be created by the user, but be a result of a query (maybe the first example).
My point is, we may use them. I'm not a fan of prohibiting just for the some particular cases.
Cheers.
William Martinez Pomares
Architect's Thoughts
Not really. As mentioned above, you can use the date for a query (I need the state report generates last month) or as a path (the month is part of the path).
The above example has nothing to do with the versioning problem! If yr resource is a report and one of the criteria is a month then it HAS to be part of either the uri or the query.
My point is, we may use them. I'm not a fan of prohibiting just for the some particular cases.
except versioning! :)
The above example has nothing to do with the versioning problem! If yr resource is a report and one of the criteria is a month then it HAS to be part of either the uri or the query.
Granted!. You got a point there: "Best practice is not to use dates as a way of versioning".
William.
Isnt this... First, not explicitely defining semantic is bad.
...a contradiction of this?Second, methods multiplicity is not a WS requirement. I have seen systems implemented using "DoWork" method (take a look at JBoss ESB) and pushing semantics into the message content.
Like you said, in an SOA, open service contracts is considered bad practice.
Thanks William.
I have to admit my REST understanding was sorely lacking.
I read James Webber et. al. article that Dilip refrenced and thought that I had a better understanding of REST.
But then I read Roy's Blog entry and came away with a completely different - and much more accurate picture - of REST.
I agree that REST is for building networked applications that are resilient to changes and as such REST is quite hard. REST is a kind of meta-application strategy.
What passes is the name of REST is not REST as Roy intended. These are mostly HTTP based API's are erroneously labeled as REST. Missing or lacking is the use of Hypertext, HATEOS or standard media types.
Without standard media types, REST APIs are only as brittle or resilient as their Web Service counter parts.
SOA fills a specific need and it seems to be working well in enterprise scenarios.
Hello Dilip.
Isnt this... First, not explicitely defining semantic is bad.
...a contradiction of this?Second, methods multiplicity is not a WS requirement. I have seen systems implemented using "DoWork" method (take a look at JBoss ESB) and pushing semantics into the message content.
Not really. I read no semantics at all is bad, but semantics in terms of method multiplicity and RPC are still as bad. Better is a uniform interface, that "DoWork" method, with semantics pushed to the message content. But that is still a little bad.
Best is a uniform interface with NO method. Just a port where you deliver a message: control, payload and semantics are in the message, which is one way. NO RPC.
William Martinez Pomares.
Great to hear that, Faisal!
Not sure when REST became a marketing tag you have to wear to be popular, but I feel that more an more people are getting to see that REST is a different kind of animal, not as easy to domesticate. Probably soon we may be able to get real benefit from it, not just a marketing aid.
William Martinez Pomares.
Best is a uniform interface with NO method. Just a port where you deliver a message: control, payload and semantics are in the message, which is one way. NO RPC.
This essentially means that there are no shared (agree-upon) semantics, just a single "processThis" method. This, in turn, means that your infrastructure doesn't know anything about your messages.
In RESTful HTTP, the infrastructure can do things differently for GET, POST, PUT and DELETE requests. This is one, if not the, major benefit.
Dilip,
I agree, that shared semantics is challenging (altough we should not to resign). But being explicit is crucial for EAI quality. I wrote short entry about what I expect from new approaches/methods/tools in EAI and why is "EAI REST" not interesting for me (altough it can be fun to play with on selected small problem).
Peter,
1) Could you tell us what the differences between core- and management-/support-processes are, that only the latter are appropriate for REST??
2) The Resource Oriented Enterprise (ROE) is not a "meaningless term", much less it tries to re-define the term Resource. It is a fictive enterprise that uses a Resource Oriented Architecture as foundation for its SOA initiative. That's a free choice. REST is a distributed architecture style, so are procedural WebServices and WS*-stack.
If you had read a little about ROE, you would have seen that it exactly tries to supersede the gap between your points 2A and 2B. It considers RESTful principles and the REST vocabulary as good communication basis between business and IT, mainly due to URIs and the Resources, two concepts, that are easy to understand (and already well understood) by business folks.
-- Juerg
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
35 comments
Watch Thread Reply