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. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
