On Wed, May 14, 2008 at 3:16 PM, Tammo van Lessen <[EMAIL PROTECTED]> wrote:
> Hi Assaf, > > > Assaf Arkin wrote: > >> 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 >> JSON. >> > > Thanks, point taken. That it very interesting! Sounds like theory and > practice aren't aligned here as well :) I should spend more time with > playing with code... I'm working now on a task manager for ODE, it's a sandbox project, if you want to have a look at it. Great place to experiment with some of these issues, specifically because it serves both end-users and workflows, which have different requirements. And also because it will be pulled by the forces of too-much AJAX on one side, and fondness for EJB/HTTP on the other side. Assaf > Cheers, > Tammo >
