ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: [gsoc] Monitoring Console / Architecture
Date Tue, 13 May 2008 22:06:05 GMT
On Tue, May 13, 2008 at 2:19 PM, Tammo van Lessen <tvanlessen@gmail.com>

> Assaf Arkin wrote:
>> And for the XML allergic (count me in) I Abdera has a JSON
>>> representation as well.
>>> Then for the view, I'm sure there are some JS Atom readers that would
>>> also
>>> help a lot (I know JFeed for JQuery, dunno if there's one for prototype).
>>> So
>>> standardizing on Atom would also help us there. Everybody knows how to
>>> render an Atom feed these days.
>> Yes, but I'm not convinced rendering a JSON feed would do our end-users
>> any
>> good.  Anyone interested in reading JSON?
>> Most people would prefer a nicely styled HTML page, so now that JSON has
>> to
>> be converted into HTML on the client-side.  Or you could just send HTML
>> directly from the server (for the buzzword inclined, it's called AJAH).
> Anyone interested in reading Atom? Probably not. That's why I suggested to
> have 2 representations of the same resource. The resource contains always
> the same information, rendered as different representations for different
> audiences. For humans, the HTML representation is best, for Atom clients the
> Atom representation. One URI fits all, so the SWT GUI could use the same
> entry point as others via a web browser. This is on the abstract level. On
> the detail level there may be some pitfalls as browsers don't support PUT
> and DELETE, so there is some JS needed to emulate these verbs via POSTs.
> In general, this is not mixing up APIs with UIs. This is actually a unified
> API for different audiences, i.e. people and machines and that's what IMO
> content negotiation is about.

Here's four things I learned from trying to do that, which just didn't work.
 There's more, but I think these four would be enough:

1.  Quite early into the development you realize the UI and API are
optimized for different tasks, they quickly diverge and you end up with
components that have UI and API functionality, but they don't always
overlap.  It seems like a good idea -- reuse -- but the resulting code is
unfortunately harder to maintain than keeping the two separate.

2.  If you're coming up with a new version of the API, it's generally a good
idea to place it elsewhere than the original version, so each version gets
its own resources.  If you're coming up with a new version of the UI, it's
generally a good idea to place it where the old version was, preserving as
many resources as possible.

3.  The API response to creating a new resource is 201, the UI response is
303, unless you want some JavaScript code back to render the change, in
which case it would be 200.  The URL for an API update would point to the
resource you're changing (with a PUT), but the URL for a UI update would
point to a form which will then be used to make the update.

4.  If you can request the same resource as HTML or JSON, you can imagine
using one to render a full page, and the other to just pull new data and
update existing page in-place.  Except browsers don't handle Vary, so the
second request would bring the cached HTML copy instead of the expected


> Nevertheless I'm of course fine with having a JS application separately
> that simply uses the API. In this case I'd opt for a JSON representation as
> these snippets can be directly processed in JS without a need for parsing,
> data model etc.
> Cheers,
>  Tammo

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message