This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Resources

Stefan Tilkov,

Jean-Jacques Dubray about Data Centric Interfaces:

ebXML BPSS is, I think, a form of “data centric” interfaces. Resources being exchanged are explicitly defined as business documents that are exchanged via document envelopes. […] Of course Paul’s point is about the superiority and simplicity of REST versus SOAP.

I disagree — in a REST scenario, the resources are addressable entities; it’s their representations that are exchanged. I also don’t see SOAP and REST being in any way mutually exclusive.

On June 29, 2004 5:06 PM, Jean-Jacques Dubray said:

Stefan:

your permalink is broken so I am replying here. The question I raise is what is a Data centric interface (i.e. by opposition to operation centric in the web services world).

Interface should define how you can interact with what’s below the interface. An interface relates to some or all boundaries of its implementation.

I understand that REST recommends how to implement a data centric “interface” via representational state transfer (GET this_entity), but REST does not let me express the constrains expressing the boundaries of an interface. When you disagree with me, do you imply that when dealing with data there is no need for such boundary? REST also provide no way to express the behavior of an interface be it data centric or operation centric.

In other words my question was how do you define the contract of a data centric interface? REST tells me how to implement it not how to specify it. I am okay to agree that REST offers a really good implementation model.

Jean-Jacques