Re: [rest-discuss] How much REST should your Web API get?
- On 02.05.2013, at 13:24, "jerome.louvel" <jlouvel@...> wrote:
> After living with REST for 10 years and introducing in 2005 the first REST framework for Java (http://restlet.org), I felt that by pushing REST too far we are just trying to make it solve problems it was designed for in the first place.I remain a strong proponent of the idea that it is more fruitful to aim at rethinking the problem to fit a sound paradigm rather than to blame the paradigm for not fitting the problem (one's perceived view of it, that is).
> In this blog post, I tried to formalize a "Web API" architecture style and contrast it with REST, then introduce the idea of cross-device web sites as wrapping the power of both styles:
> Interested in hearing what you think!
Two concrete points:
I don't buy the efficiency argument regarding discovery and granularity of messages - unless you ignore caching and the possibility to tailor representations for specific devices.
You write about the 'Web API style' "requires coordination between clients and servers when changes are deployed" - doh... this eliminates *the* (**the**) primary benefit to apply REST.
Aside from systems that focus on sending fine grained control messages around in (near) realtime, I have yet to see a case where REST does not shine due to performance, scalability and the ability to decentralize management of the deployment and release cycles.
> Best regards,
> PS: sorry for those also following the "API-Craft" mailing list, but the topic is right at the crossing of both communities.
- Once again you have given me much to ponder. Thanks for the effort; I will be trying to internalize this.
On May 4, 2013, at 1:49 PM, "Markus Lanthaler" <markus.lanthaler@...> wrote:
> On Saturday, May 04, 2013 7:03 PM, Mike Schinkel wrote:
>> Hmm. Okay, the more I think I understand about REST the more I think
>> I don't understand and/or am unsure who actually really understands
>> REST besides Roy.
>> As I've read Roy I've come away understanding that messages must be
> No, you are confusing self-contained with self-descriptive.
>> and the only thing the client should know is how the
>> links in the returned representation are defined to behave as defined
>> by the representation's content yype. Having links in one document and
>> data in a second document where you have to have the contents of both
>> documents seems to me to violate that need for self-containment.
> ... if there would be a self-containment constraint that would be true --
> but there isn't.
>> I do have one question; if there is a home document that is cacheable
>> for some period "X" and at the time immediately after an API client
>> retrieves the home document the servers are moved and the client later
>> perform an operation that requires URLs from the home document but
>> before "X" time has passed, it can cause failure. If the message is
>> self-contained that time window is greatly reduced. This is one of the
>> reasons I can postulate there is a need for self-contained messages.
> That doesn't matter at all. Program defensively, detect the error, and
> I could just as well argue that separating them allows you to request them
> in parallel which would probably be faster so the time window you are
> talking about would be reduced even further.
> Markus Lanthaler