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...
Cheers, Tammo
