News for hackers. Stuff that matters.
Re:The one true REST explanation by scott_s on Friday November 12, 2010 @12:08PM (#1898300)
I understood it to be decoupling the what from the how. In this case, it decoupled knowing that you needed to book an appointment from the URI that lets you do that.

If I already what what I want to do, but I allow a service to tell me how to do it, me and the service have a looser coupling. If the service decides to change how I accomplish the task, then I should seamlessly adapt.

Re:The one true REST explanation by stevenwei on Friday November 12, 2010 @05:57PM (#1899636)
But, in practice, how often does a service change an URI only, without changing the input or output parameters (causing you to have to re-factor your client anyway)?
Re:The one true REST explanation by drewp on Saturday November 13, 2010 @04:52AM (#1900640)
Often merely moving from the dev environment to the release environment changes the URIs. Sure, you could try to minimize the part that changes between environments and teach all your clients to form correct URIs between environments, but it's still coupling. And dev/prod is hardly the only thing people find themselves adjusting in URIs; it was just an example.
Re:The one true REST explanation by wahnfrieden on Saturday November 13, 2010 @03:24PM (#1901613)
One example, if you move domains, all you'd need to do is redirect the single entry point URL to the new one without having to force clients to change anything and with having to redirect every single API request.

You can also allow other sites to implement the same API and clients would only have to select a different entry point. Look at AtomPub for instance.