So let's imagine I want to create new web site that will provide blog editing functionality and I will want to integrate with existing blogging systems. All of them provide HTTP access to insert new posts, comments, and so on. Users of my site will edit new posts in my editor and publish them on their blog servers.

So beside writing the superb editor I have the integration task. Can you explain how much easier this task is with REST than with WSDL? All I see is that if I want to support one more blog server ('the new service added to the system') I just need to write new integratoin code into my editor. In both cases.

If there was strict payload agreement then, of course, the integration would be easy. I'm sure APP will solve this for one domain. Some GData-like solution for another domain. We are not there yet on the Web and certainly not in enterprise.

Best,
Radovan

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

On 7/6/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> Now either I've been incredibly lucky or I only build mickey mouse
> apps... but I've never had this problem.

Another possibility is that you don't realize how simple things can
really be? That's how it was for me, at least.


> What form of scalability are you refering to?

Number of services. With Web services, for each new service that's
added to the system, in order for existing components to be able to
communicate with it, you have to modify them (ignoring the data issue,
which is the same with both). Not so with REST.

In technical terms, integration complexity with Web services is
typically O(NlogN) (O(N^2) worst case). With REST it's O(logN) (O(N)
worst case). There are even REST extensions where you can achieve
O(1) at scale (e.g. weblog aggregation, search). SOA is totally
heading in the wrong direction in terms of scaling.

Mark.




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


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to