Hi, On Mon, Feb 16, 2009 at 2:46 PM, [email protected] <[email protected]> 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
