On programming models...

Ittay Dror fails to grasp the fundamental fact that Representational State Transfer (REST) is not an application-programming interface (API) at all. REST is not a technology. REST is not a set of technologies. REST is an architectural style for network-based hypermedia applications. Version 1.1 of the Hypertext Transfer Protocol (HTTP/1.1) is a specific technology that offers an API of sorts. HTTP/1.1, when used as co-designer Roy Fielding intended that people use it, almost conforms to REST and is part of an application (the World Wide Web) that itself is somewhere in the vicinity of conformance to REST.

Chew. Digest. And please return for dessert. ( http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm )

I agree with what you are saying about REST, although I think the phrase "hypermedia application" makes a lot of people think "oh, it's not for me". Anyway, to be fair to Ittay, you do have to have some programming model to implement your system and his point is that if you implement a design based on REST principles, you aren't doing RPC. That's a struggle for people because the method call has been the atom of abstraction for a lot of developers for a lot of years.

Tim-

I think you completely missed my point.

So I chose REST. Great. Now what? I have to implement it somehow. How? Using a programming language. Say, Java. But then Java is all about methods, invocations, getting return values etc. Not about resources, state, hypermedia. Which means classic design doesn't work. I have to build my Java application in terms of resources, state transitions etc., just because I chose to expose its functionality as REST. Of course I can do it, but it means the API (REST) fundamentally governs how my application is developed, which I don't like. It means there's no separation. For GUI, we always advocate MVC as the paradigm for separation. But to use REST, it is very hard to use a paradigm that gives me the same kind of separation.

Ittay,

You're right, if you choose REST, classic design doesn't work. But what I think you mean by "classic" is method and/or object-oriented. Of course that design style doesn't work, because REST is a different model. That doesn't mean you can't implement RESTian endpoints using object-oriented design, which we do for Web sites all the time. We can use a similar MVC layer to implement arbitrary REST protocols too.

In this respect REST is no different from other altneratives to RPC: sockets and message queuing and tuple spaces sping to mind. None of these mechanisms for distributed communication is method or object based, but they all offer capabilities that are hard or impossible to implement in RPC systems.

If what you want, though, is seemless mapping of distribution technology to methods on objects, by all means use RPC. But understand that there are alternatives out there that offer better solutions to many problems.

Tim-

uVK6kd  <a href="wzlocijynpry.com/.../a>, [url=http://ubuskutkyghl.com/]ubuskutkyghl[/url], [link=http://ctbhgvgtunmb.com/]ctbhgvgtunmb[/link], http://vkxwcnlwhabj.com/