REST is not the answer to all your problems
I've been following Duncan Cragg's REST dialogues for a while, and they contain a lot of useful and interesting ideas. However when we meet in the pub or office we don't entirely agree when it comes to REST.
I think at the root of my concerns is the idea of the underlying protocol and it's relationship to the business semantics. I believe the quality of service and business semantics of the integration solution we are building should drive the choice of implementation, not the other way around. So in some cases we may choose a message queue, in others a messages bus and maybe in others REST.
I'm wary of choosing an implementation and then trying to model the world in terms of that implementation, shouldn't we be doing things the other way around? Personally I think that businesses view things in terms of services, that one part of the business provides a service to another part of the business - with particular expectations around the quality of service that will be provided. So the idea of services seems to be one that is shared between business and IT, it often makes it easier to understand the business need for a piece of integration. To be super clear, when I say SOA I do not mean WS. For me REST and web services are implementation choices I make after I've understood what the business needs, SOA is a nice way to model and understand those needs.
I've commented on Duncan's latest post here, I expect we'll continue to disagree over a pint next time we meet :-)
I think at the root of my concerns is the idea of the underlying protocol and it's relationship to the business semantics. I believe the quality of service and business semantics of the integration solution we are building should drive the choice of implementation, not the other way around. So in some cases we may choose a message queue, in others a messages bus and maybe in others REST.
I'm wary of choosing an implementation and then trying to model the world in terms of that implementation, shouldn't we be doing things the other way around? Personally I think that businesses view things in terms of services, that one part of the business provides a service to another part of the business - with particular expectations around the quality of service that will be provided. So the idea of services seems to be one that is shared between business and IT, it often makes it easier to understand the business need for a piece of integration. To be super clear, when I say SOA I do not mean WS. For me REST and web services are implementation choices I make after I've understood what the business needs, SOA is a nice way to model and understand those needs.
I've commented on Duncan's latest post here, I expect we'll continue to disagree over a pint next time we meet :-)
posted by Ian Cartwright at 11:09 AM
7 Comments:
Hey Ian,
Are events or messages necessarily any better abstractions than resources for modelling a problem domain?
Jim
That depends on the problem domain, I think we have to understand the domain and then choose the most appropriate implementation. Might be events, messages or resources - there is no silver bullet.
>I'm wary of choosing an implementation and then trying to model the world in terms of that implementation, shouldn't we be doing things the other way around? Personally I think that businesses view things in terms of services.
REST isn't an implementation of a Service Oriented Domain Model.
Businesses may or may not see services - I haven't polled them, but /I/ suspect that, in fact, most see data. The REST perspective deals directly with the data-oriented way of seeing their business.
ROA vs SOA is a choice which makes it easier to either model your business as resources or as services. I prefer the former, you the latter.
REST isn't an implementation choice for a service perspective.
And, of course, you can do all your reliability, security, messaging, transactions, etc. in a REST model when you come to implement it. My Distributed Observer Pattern is one of many approaches that you can draw on.
Publish-Subscribe events (declarative messaging) map as neatly onto ROA (a declarative architecture) as Message Queues and the command pattern (imperative messaging) map on SOA (an imperative architecture).
That's why 'REST vs SOA(P)' is such a permathread - they're polar opposites or 'duals' of each other, so you tend to be forced to choose, and they are probably impossible to reconcile.
Ian, good post.
I've posted an entry in my blog about REST vs message passing where I distinguish which to choose based on a fundamental characteristic of the architecture:
REST for request/response in a client/server architecture, and
message passing for an asynchronous or P2P architecture.
John
For me REST and web services are implementation choices I make after I've understood what the business needs
Thanks for being a rational voice to the needless arguments over which approach is best. As with most architectural decisions there is no silver bullet - design approaches will be influenced by business requirements.
For me REST and web services are implementation choices I make after I've understood what the business needs
Thanks for being a rational voice in the REST vs. everything else debates. As with most architectural decisions there is no silver bullet - design approaches will be influenced by business requirements.
The whole needless discussion is on the difference or benifit in going either the client/server (REST) or message passing (SOA) way.
To admit, implementing SOA is bit more complex than REST. It is not that it is intensionally made complex, but it actually handels complex stuff.
SOA deals with messages with body and header, which at times might become a network overhead without achieving much, where in REST make it a must to have a response for every dam thing you send, which might not be a liking for many architects.
It is all about your need of the application and how bad/good your underlying design. Either of them can't do any magic as you are the guy who is at the end of the day implementing it :-)
Post a Comment
<< Home