esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: API2 - response format changes - request for input
Date Tue, 03 Nov 2009 05:02:31 GMT
Are the breaking changes just in the API2.scala code or in other scala
classes as well.

Since I don't think anyone has built any clients using the new API, I
don't think we should have any problems.

I'm glad to see any changes that make the API more REST-like (be it
using tags instead of attributes, etc.) inasmuch as I'm not a REST
expert, I'll leave you to judge whether the changes are appropriate or
not.  Maybe, you could reach out to others on twitter with more REST
experience and ask them.

D.

On Mon, Nov 2, 2009 at 9:16 PM, Ethan Jewett <esjewett@gmail.com> wrote:
> All,
>
> This email is half warning of breaking changes and half request for
> input. I'm working on major changes to the response format of the
> current API in the API2 endpoint. Those changes amount to:
>
> 1. The current format wraps all responses in a tag that defines the
> operation, the success/failure, and an optional message. I'm planning
> to drop this completely, with an interim step of dropping all the
> attributes and leaving the tag. In my opinion, the HTTP response code
> should indicate the success/failure, the HTTP method and URL defines
> the "operation", and the message ... well, I'm not sure what the
> message is for.
>
> Dropping this stuff and putting it into the actual HTTP codes is going
> to involve dropping the use of the XMLApiHelper trait since that trait
> doesn't seem to work this way at all. That change is coming in the
> next patch.
>
> Thoughts?
>
> 2. The current API tends to use a lot of XML tag attributes to convey
> information. Though this format is more concise, I would like to
> switch to using nested tags to convey the information that is
> currently conveyed through attributes. I find this more idiomatic
> based on my use of other APIs, but it will also (I think) ease the
> ability to convert the responses to JSON later on since JSON doesn't
> seem to have built-in support for attributes. Thoughts on this?
>
> The approach here is to write my own helper methods to convert ESME
> objects (User for example) into XML Nodes, since if I override the
> .toXml methods of the existing objects it will change the response
> format of the current API and break things. I figure later I can write
> a wrapper to match against the HTTP Accept header in order to convert
> the Node into the return format that the client is requesting (default
> to XML, but also provide JSON, for starters).
>
> Thanks,
> Ethan
>

Mime
View raw message