![](https://secure.gravatar.com/avatar/2e8a29939ae47bcb3f13355216707cfe.jpg?s=120&d=mm&r=g)
I think that you have missed a level of abstraction.
The service, per se, does not REQUIRE a REST interface in order to operate. It only requires an implementation (in any language) and mutually agreed intra-service bindings in a mutually acceptable language.
Because we have chosen a RESTful mechanism as a communications medium for services hosted on separate processors, we will need a REST interface specification. But, that REST interface is only one implementation of the service interface. The REST particulars are not really a part of the service.
Including the locations, etc. are details of a REST IMPLEMENTATION of the service interface in the same way that Python classes and methods would be used to define a python interface. Or C++ class headers, etc.
Richard
On Jul 13, 2012, at 7:02 PM, Barry Warsaw wrote:
On Jul 13, 2012, at 05:43 PM, Richard Wackerbarth wrote:
I wouldn't even go that far. The service does not need to be DESCRIBED in terms of locations at all.
Certainly, somewhere in the implementation, we would have to provide that CONFIGURATION information, but from the perspective of a consumer of the "user service", my interface is akin to (expressed as meta-language, not code)
services.user_service.change_password(user_identifier, new_password, ... )
It does not matter where, or how, the user_service processes that information except to the extent that I, and the another services, expect it to persist and can later enquire
password_is_valid = services.user_service.verify_password(user_identifier, submitted_password, ... )
Actually, I think it's essential that we describe the service in terms of resources and locations. The pseudo-code above is an example of a language binding, but isn't enough because the implementer of that binding would not know where to point the proxy, or how to do the HTTP calls, etc. In fact, the pseudo-code would look significantly different depending on what implementation language is used (the above looks Pythonic, but what about Ruby, or JavaScript?).
If we're using REST then the description of the service must be in terms of the API that REST exposes, e.g. URLs and JSON (for example). Then authors of the language bindings can expose them to client code in whatever way makes sense.