I know. But agreement on data semantics is the big problem. Operations (if it is not the part of the agreement already) are piece of cake compared to that.

Advantages of REST are mainly in non-business logic levels - proxies, caches, and so on. And if you add ubiquitous HTTP (even if not RESTful often) then it's clear winner candidate. And it will if we manage contracts somehow.

As for my blog example, you didn't tell me how easier it is to do the job yet. And I don't want to assume they share data semantics. This assumption is nice but not real. But we can assume they are RESTful.

Radovan

On 7/7/06, Mark Baker <[EMAIL PROTECTED]> wrote:

On 7/7/06, Radovan Janecek <[EMAIL PROTECTED] > wrote:
>
>
> But Mark that was my point. In order to really save time and decrease complexity you need to agree on the data.

Right! So in these examples, let's just assume both sides agree, a
priori, on the data. That allows us to focus on the complexity of
interface (or "API" if you prefer) integration.


> If there is no agreement then integration of my editor is about of the same complexity in both cases regardless of your logarithms ;-)

Nooooo! 8-O You're ignoring the interfaces!


> And, btw, the fact that APP and GData are on the Web proves there is a further need for simplification beyond REST academia.

Absolutely. There's still work to be done. Just a lot less than
SOA/WS would have you believe.

Mark.




--
Radovan Janecek
http://radovanjanecek.net/blog __._,_.___


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to