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 :-)


