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.
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
