![](https://secure.gravatar.com/avatar/173371753ea2206b9934a9be1bdce423.jpg?s=120&d=mm&r=g)
On Jul 13, 2012, at 11:57 AM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
I don't see any reason why it couldn't be mapped to a REST API; it's just a lack of need, and nobody's written it yet. The question is whether IUserManager is actually the right API for a REST interface - in general I don't think you need a 1-to-1 mapping of internal model or APIs to REST.
My suspicion is that in particular (ie, when addressing a specific set of requirements) you don't need a 1-1 map of internal APIs to REST.
I agree.
But if you want World Domination (and you have expressed that ambition on occasion), you need a system that grows new complex functionality organically. That, I think, means that we want various parts of the system to cooperatively build a single database that is offered to all components.
If you want to say, OK, I'm not really serious about that, that's fine by me: we *need* a killer MLM, and Mailman 2 isn't it (any more). But if you want to try for World Domination, I think the database (ie, the "social network engine") is the one component that's going to make or break that enterprise.
I don't necessarily disagree with any of that, but that doesn't necessarily mean that the API exposed by the core needs to provide that database. OTOH, a separate user database component certainly could expose that stuff, and where the two systems overlap in their support for the uber-model, certainly the resource locations and semantics should be as close as possible.
As an example, the core currently exposes just a few attributes at the user resource in REST: user_id, created_on, password (optional), and display_name (optional). These live at <baseurl>/users/<userid>. If the separate user database also kept track of things like Facebook and Twitter ids, these would also be available at the same location (different base-url of course) and the returned JSON would just contain additional entries for that extra data.
We've just planned ahead and made the relationship between members and the mailing lists based on the fqdn_listname of the mailing list[*].
This should be the List-Id. RFC 2919 essentially says that the mapping of "mailing lists" (whatever *they* "really" are) to List-Ids is 1-1 by definition. I think that in practice this is probably going to work well, in the sense that people who thoughtlessly initialize a new List-Id when they migrate domains probably don't think (much) about the fact that it's a new list, while people who take the care to keep the same List-Id surely do care about the list's identity.
LP: #1024509
zope.interfaces, just that we have to be able to implement the methods and properties defined in these interfaces using REST calls.
Probably a good start would be:
- IAddress
- IMember
- IRegistrar
- IRoster
- ISubscriptionService
- IUser
- IUserManager
This list kind of worries me -- it's very specific and fragmented. Is there a higher-level way of doing this mapping?
There's not unfortunately.
[**] Hey Florian, continuing on a theme, maybe "Vicious". Get it? :)
I see ....
I think we'll have to start calling the core engine "Lee", since as we all know, it should be the center of attention. :)
-Barry