Hi all,
I've been looking around for a description of the REST API in Mailman3. Fact is I couldn't wait more and started a REST API for Mailman2. So, I would like it to be as close as possible to the final stuff.
-- Fil
On Jun 13, 2010, at 09:42 PM, Fil wrote:
I've been looking around for a description of the REST API in Mailman3. Fact is I couldn't wait more and started a REST API for Mailman2. So, I would like it to be as close as possible to the final stuff.
The documentation on http://packages.python.org/mailman is out of date, but ultimately, that will be the best place to look. For now, the current bzr head is the best place to start:
http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/files/head:/src/mail...
This is unformatted, but should be easy to read.
I should also mention that if you have requirements for additional REST APIs, the best thing to do is to file bugs in the tracker:
https://bugs.edge.launchpad.net/mailman
Please add the tags 'rest-api' and 'mailman3' so the bugs are easy to find. Tracking requests via bugs will help me prioritize the work.
Cheers, -Barry
For now, the current bzr head is the best place to start: http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/files/head:/src/mail...
This is unformatted, but should be easy to read.
yes that's perfect, thanks a lot.
I see no mention of access control. Will we use OAuth or something?
-- Fil
On Jun 16, 2010, at 09:31 PM, Fil wrote:
I see no mention of access control. Will we use OAuth or something?
Well, this is an interesting question <wink>.
The way I've been thinking about it has been that the REST interface currently in the core engine is essentially an unprotected administrative interface. We would only ever expose it by default on localhost. For a publicly accessible REST front-end, we'd use OAuth and lock down permission based on privilege, but this would be a separate process and interface from the core.
I know that's somewhat controversial but given the nightmarish complexity of lazr.restful and Zope's publisher, it was IMO an entirely justified architecture. With the switch to restish, it may be feasible to put security in the core. The tricky thing is doing this for end-user scripting while still allowing something like the webui to have unlimited, essentially root access.
-Barry
The way I've been thinking about it has been that the REST interface currently in the core engine is essentially an unprotected administrative interface.
I see...
Another (interesting?) question is how do you encode data esp. if an email address or username contains a slash (/) character.
-- Fil
On Jun 16, 2010, at 09:56 PM, Fil wrote:
The way I've been thinking about it has been that the REST interface currently in the core engine is essentially an unprotected administrative interface.
I see...
Another (interesting?) question is how do you encode data esp. if an email address or username contains a slash (/) character.
AFAIK, if it's encoded properly by the client (e.g. Python's httplib2), then the restish library should properly decode it. It's worth a test...
going-off-to-hack-ly y'rs, -Barry
How would I query members of list A? GET 'http://localhost:8001/3.0/members' + A ?
If my mailing-list has thousands of members, how would I paginate the results? 'http://localhost:8001/3.0/members' + A + page=x ?
-- Fil
On Jun 17, 2010, at 12:03 AM, Fil wrote:
How would I query members of list A? GET 'http://localhost:8001/3.0/members' + A ?
In the Bazaar trunk, r6914 <wink>, for mailing list alpha@example.com, if you want all the subscribed members, you would request:
http://localhost:8001/3.0/lists/alpha@example.com/roster/membersIf you want the owners of the list:
http://localhost:8001/3.0/lists/alpha@example.com/roster/ownersand if you want the moderators:
http://localhost:8001/3.0/lists/alpha@example.com/roster/moderatorsIf my mailing-list has thousands of members, how would I paginate the results? 'http://localhost:8001/3.0/members' + A + page=x ?
Pagination is not yet supported. One of the deficiencies of restish as opposed to lazr.restful is that the former does not support collections out of the box. I have a CollectionMixin class to handle those, but it doesn't yet know about batching. Contributions are welcome!
(The plus side of restish of course is that it only took me about two hours to add support for rosters, and most of that time was refactoring, writing the tests, and fixing a regression with the zope.testrunner integration. Read: easy peasy!)
Cheers, -Barry
participants (2)
-
Barry Warsaw -
Fil