This is maybe the muddyist thinking I've ever read. He tries to draw a distinction between SOA "Services" and REST "Resources" but it doesn't work because a "Resource" is just the end product of a "Service". So really he's just jumping through his own mentally created hoops (I bet he's the type that writes 40 pages of Workflow and UML diagrams before he ever writes a line of code)

Whether you use SOA or REST it's still still just an interface to the same functionality. How you choose to think about it is all in your head.

Wait a second.

1. "...it doesn't work because a "Resource" is just the end product of a "Service"...". I think we need to review the concepts. A resource is an abstraction, a thing that lives on the web, in no particular place, and that may have more than one representation. Actual implementation of a resource can be anything, and one option is to built a service. 2. Nor SOA nor REST are interfaces! Wrong, they are architecture styles. 3. Agree, same functionality can be achieved using either style. But app is not only the functional part, but the quality attributes too, and REST/SOA have different architectural constrains to deal with those attributes. 4. Finally, you are right, YOu can choose what to use, but it is not good to confuse them.

I have data. I want you to be able to use that data. I create a service so that you can INTERFACE with my data.

Again, the reason "Information Architecture" has become a dirty word in most IT organizations is because of these little mental circles. Like when you say "Actual implementation of a resource can be anything". What does that even mean? Are you saying there's some form of "resource" that isn't data of some kind? Because if all resources are data of some kind than there has to be some process to deliver that data. That process is called a service. Hence resources are the end result of services (as I said)

Hi SamAtt. You know, your posting is fun to read. Nice.

Still, the reason "Software System Architecture" or anything with the architecture name on it, has become a dirty word is because there is no understanding between an abstraction and a concrete thing. What you picture is known as Intellectual Violence, an architectural antipattern. In my case, if I want to talk about data, I say data. If I want to talk about information, I say information. They are not the same thing. SO, if I say resource, it means it is not data nor service. A resource can be a document, data, a service, a process, a whole system, anything.

So, as you can see, that is no mental circle, I really mean anything. If you think a resource is just data exposed as a service, then you are missing thousands of other resource implementations. Why call it resource and not data, service or system? Because resource is an abstraction, that allows me to work it without knowing what the final implementation would be.

Cheers!

I think the blog post clearly mentions that there is indeed one standardised resource management service for REST over HTTP, and given its simplicity and ubiquity, that particular standardised service orientation is uninteresting and largely ignorable.

When I find someone disagrees with me I tend to either try to elaborate on my point or present a counter point to their argument. Not just quote what I've already said. You should try it