[Mailman-Developers] Mailman 3 REST API URLs

[Barry Warsaw]

On Jul 20, 2010, at 04:50 PM, Florian Fuchs wrote:

>For example: At the moment an API request
>to /3.0/lists/listname at example.org exposes only some basic list
>information. Would it be a good idea to let this URL expose more list
>details (i.e. all list settings) or would it be better to have a
>different URL for that? (Something
>like /3.0/lists/listname at example.com/settings).

I don't think these need to be mutually exclusive, but of course it's a matter
of deciding which approach is more useful to implement first.  I think the
former will be easier to implement from the server side.

Both will accomplish what you want and will have different performance
characteristics.  For example, GET on /3.0/lists/listname at example.com can
return the entire representation of the mailing list object.  POSTs to this
would *replace* the state of the object with the new state, but PATCH (which
is a non-standard HTTP verb though supported in e.g. httplib2 IIUC) will allow
you to modify a small subset of the list's attributes.  This can be much more
efficient if you're patching a bunch of attributes at the same time because
you'll only need to make one request.

I think it comes down to what wui interactions you expect to implement.  If
you think it'll be more common to change one attribute at a time, then perhaps
we should implement lists/settings/foo first, but if you think it'll be more
common to change a number of settings in a batch, then implementing PATCH on
the list object first would be better.  (Aside: I'm not actually sure how best
to implement lists/settings/foo ;)

>So if we went for the latter option: Why not go even further and
>access the settings field by field? Or in smaller groups,
>i.e.: /3.0/lists/listname at example.com/settings/archiving

I suppose we could implement categories but I see these as an artificial
organization in Mailman 3.  Mailman 2 had them as an artifact of the
implementation, but I never really liked it.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20100723/4f44e6ff/attachment.pgp>