[Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

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.