Differences between revisions 39 and 40
Revision 39 as of 2009-04-01 14:12:45
Size: 5376
Editor: p@state-of-mind
Comment:
Revision 40 as of 2009-04-01 14:17:59
Size: 5401
Editor: p@state-of-mind
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#pragma page-filename DEV/versions/7962749 #pragma page-filename DEV/versions/7962751
Line 52: Line 52:
[[DEV/Initial Considerations]]<<BR>><<BR>><<BR>><<BR>> [[DEV/Initial Considerations]]<<BR>><<BR>><<BR>><<BR>><<BR>>
Line 108: Line 108:
|| Specific settings related with a person (identity, MIME-settings, Vacation, etc.)<<BR>> || Specific settings related with a person (identity, MIME-settings, Vacation, etc.) <<BR>>
Line 111: Line 111:
|| A list of all <<BR>> || A list of all members (address, mailinglist, role) <<BR>>
Line 114: Line 114:
|| TODO: What's beneath? || membership management (moderated, unsubscribe, etc.)<<BR>>
Line 117: Line 117:
|| A list of all email-addresse the system knows about<<BR>> || A list of all email-addresses the system knows about <<BR>>
Line 119: Line 119:
/addresses/<address><<BR>> /addresses/<address> <<BR>>
Line 123: Line 123:
|| returns list of (mailing list name, URL, public/private flag) tuples. POST is used to create a new list and redirect || returns list of list-ids (mailing list name, URL, public/private flag) tuples.
Line 132: Line 132:
|| TODO: What does it list? <<BR>>List all lists within a domain? <<BR>>Configure global/default settings of all lists within the domain? <<BR>> || List all domains within the site (hostname, web hostname, description, contact address) <<BR>>
==
/domains/<domain-id><<BR>>
|| Manage that domain<<BR>>
Line 135: Line 138:
|| A list of all messages? No... || A list of all message-ids
Line 138: Line 141:
|| TODO: What does it list? <<BR>>Header-Info: Sender, Recipient, Date, Subject, Size <<BR>> || Header-Info: Sender, Recipient, Date, Subject, Size <<BR>>

Sketch of a REST interface to Mailman

This interface isn't intended to be exposed to the Internet at large, so there's no mention of access control. It would be used as a back-end, on top of which the existing Mailman interface, or a fancy GUI application, or administrative scripts, could be built.

Resource Types

  • Lists
  • Users
  • Subscriptions (which tie together a single user and a single list).
  • Messages

Use Cases

h3. user

  • preferences (create, modify)

Changes a user can make to his list-specific settings, but also to all of his subscriptions on the server.

  • identity (create, modify)

Changes a user can make to his list-specific identity, but also to all of his identities on all subscriptions on the server.

  • subscription (create, modify, delete)

Changes a user can make to his list-specific subscription settings e.g. preferred mail-address, but also to all of his subscriptions on the server.

h3. moderator

  • messages (approve, reject, discard, defer)

Handle pending requests.

  • subscriptions (approve, reject, defer)

Handle subscription tasks.

h3. owner

  • lists (create, modify, delete)

Manage list related tasks.

  • subscriptions (create, modify, delete)

Handle subscription tasks.

  • users (create, modify, delete)

Handle user management tasks.

  • statistics (read)

Read server, domain, list, user-related statistics e.g. Top Ten Posters, List Activity Meter

DEV/Original Use Cases

Principles

We use JSON. Libraries are available for most relevant programming languages and it's reasonably human-readable.

Also taking the recommendation of Leonard Richardson we will also honor the representation request in the Accept and Accept-Language headers.

DEV/Initial Considerations




URL Space

Unless otherwise specified, all these URLs return a data structure encoded as JSON.

URL
Action
/ List all top-level URLS
/sys List all children URLS
/sys/version Return Mailman and Python version (read-only)
/sys/plugins List all plugins (name, description, author, version)
/sys/plugins/<plugin>
Detailed info on a plugin
/stats/ List of statistics available below
/stats/site Show lists by activity (performance, tuning aspects)
/stats/domain Show comparison of lists activity within the same domain
/stats/lists list all lists within the domain
/stats/lists/<list-id> Show list activity (new messages per day, replies to new messages same day)
/stats/users/ * Top Ten Senders * Top Ten Contributers * Show a list of all users
/stats/users/<username> * Number of posts per site * Number of posts per domain * Number of posts per list * Bounces per mail-address
/users/ List of preferred email-addresses (e-Mail, Full name)
/users/<user-id> All information related to that person
/users/<user-id/<setting> Specific settings related with a person (identity, MIME-settings, Vacation, etc.)
/members/ A list of all members (address, mailinglist, role)
/members/... membership management (moderated, unsubscribe, etc.)
/addresses/ A list of all email-addresses the system knows about
/addresses/<address>
information on an address (when was it validated, link to the user associated with it, etc.)
/lists/ returns list of list-ids (mailing list name, URL, public/private flag) tuples.
/lists/<list-id> lists list homepage info
/list/<list-id>/<setting> Arbitrary <settings> that configure a list
/domains/ List all domains within the site (hostname, web hostname, description, contact address)
/domains/<domain-id>
Manage that domain
/messages/ A list of all message-ids
/messages/<message-id> Header-Info: Sender, Recipient, Date, Subject, Size

Initial URL design

Unresolved Questions

  • What to do with bounce status/other logging information?

By this I mean the info that the Mailman core will generate that the other side may need to know.

  • How should passwords be dealt with?

Should there just be a password='abcdef' setting among all the others, or should the client be expected to SHA1-encode the password or do other stuff with it?

  • In the URL paths, do we want to use human-readable list names and e-mail addresses, or identifiers?

For example, do we want /list/mailman-developers/, or /list/123456/? The human-readable names make it convenient to poke around on the REST interface, but also require us to worry about quoting can you have a list named 'foo/bar'? and people may assemble URLs instead of looking up the correct one.



Comments

Cliff Ingham

I'm needing to build a standalone webservice for Mailman that our content manager can access. I'm most comfortable in PHP, so it's probably going to be PHP instead of Python.

But it will be needing to support authentication for usage. I'm planning on it just being a wrapper for the command line tools. If folks are interested, I could contribute our code as it goes. All our work here at the City of Bloomington is GPL. Either way, I'd be very interested in seeing a native RESTful interface come with Mailman

MailmanWiki: DEV/REST Interface (last edited 2009-04-01 19:31:03 by reedobrien)