esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject Re: RESTful ESME API - Design
Date Wed, 25 Feb 2009 15:15:38 GMT
Hi,

On Mon, Feb 16, 2009 at 2:46 PM, esjewett@gmail.com <esjewett@gmail.com> wrote:
> ...I've shared a document with you called "RESTful ESME API - Design":
> http://docs.google.com/Doc?id=ajc6q3nhgqqd_374dhxctqgs&invite=cjh665s ...

I've had a quick look at the proposed API and I like it, with a few
questions/suggestions.

> ...GET api/sessions
> (It might make sense for this to return only the current session, but in
> theory it would return all sessions that the current session is allowed to
> access, so for an administrator, it might return all open sessions.  An
> individual session would be accessed at GET api/sessions/SESSIONID.)
>...
> POST api/sessions?token=API_TOKEN...

Are these HTTP sessions, or something else?
(I'm not familiar with the current EMSE API, bear with me if this is a
silly question).

Looking at your suggested API, it seems like minor changes would make
it possible to avoid HTTP sessios altogether, for example:

> POST /api/send_msg
> message=messagebody
> via=optional_name_of_client
> tags=optional_comma_delimitted_tags
> metadata=optional_XML_Element_data
> replyto=optional_id_of_message

might be replaced with

PUT /api/messages/USERID

Using a Content-Type and representation (XML, JSON, whatever) that
describes the message, using parameters similar to what you have
above. And credentials to restrict access, of course.

With this kind of change, I think you could avoid HTTP sessions, and
make the API more RESTful.

WDYT?

-Bertrand

Mime
View raw message