Re: [rest-discuss] How much REST should your Web API get?
- Excellent feed-back Robert.I have entered several issues in the GitHub project to keep track of them and ensure they are adressed in the more complete document to be published:Best regards,Jerome2013/5/2 Robert Brewer <fumanchu@...>mike amundsen wrote:Me too. And that will only be useful if folks are educated on the differences. Therefore...
> I'd like to see more work on using the "Taylor School" approach
> to modeling software arch (Properties/Qualities, Requirements,
> and Constraints)
In this case, the model needs to be fixed. "Mobility" is not a constraint, it's a requirement. Most of the bullet points in that section are requirements. "Off-line application mode" (I would rephrase it to "disconnected operation") would be the constraint. That constraint plus the cache constraint could lead to *an architecure* which syncs caches on reconnection, but that design decision is not part of the style.
Under "Custom Interface", it would be very informative to lay out in detail which of the properties are being traded off when selecting explicit versioning. Not to evangelize them over REST or vice-versa, but to understand in which situations each is appropriate.
Roy himself isn't a REST evangelist. He's an accomplished architect who has created multiple architectures using multiple styles, attempting to make them appropriate for the given requirements, both functional and non-functional (properties). We would all be wise to design our architectures with the same unbiased approach.
- 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