Re: How much REST should your Web API get?
Mike Schinkel <[email protected]> Sat, 4 May 2013 15:03:00 -0400
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <[email protected]> |
Once again you have given me much to ponder. Thanks for the effort; I will be trying to internalize this. -Mike On May 4, 2013, at 1:49 PM, "Markus Lanthaler" <[email protected]> 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 >> self-contained > > 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 > recover. > > 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 > @markuslanthaler >