Re: [rest-discuss] How much REST should your Web API get?
- <snip>I want to make clear that I don't think a second that REST has failed in any sense for what it was designed for, it is just not fully suited to the Web API space.</snip>yeah, i was generalizing and characterizing and that's a bummer. you never used the "failed" meme at all. sorry 'bout that.<snip>I'll continue working on this formalization (requirements, properties, etc.) as suggested, following the full "Taylor School" approach, via this project:</snip>i think this is cool and already added the repo to my watch list!thanks for sharing.mamundOn Thu, May 2, 2013 at 5:44 PM, Jérôme Louvel <jlouvel@...> wrote:Thanks Mike for the constructive feed-back.I want to make clear that I don't think a second that REST has failed in any sense for what it was designed for, it is just not fully suited to the Web API space.I'll continue working on this formalization (requirements, properties, etc.) as suggested, following the full "Taylor School" approach, via this project:https://github.com/restlet/web-api-styleThanks,Jerome2013/5/2 mike amundsen <mamund@...>TL;DNR- It's good to see some thinking about whether/how a single example arch from over a decade ago maps to needs of current Internet apps.- I think the approach in the blog post strays too far into a critique of assumed failures of X and attempts to "fix that" w/ mods to get X-prime- I'd like to see more work on using the "Taylor School" approach to modeling software arch (Properties/Qualities, Requirements, and Constraints)details for those who care...GOOD IDEAFirst, I like the general idea of crafting a style that meets the demands of the local use" cases instead of just adopting a style based on fad. Of course, that is the exact message of Fielding's dissertation:"...consider how often we see software projects begin with adoption of the latest fad in architectural design, and only later discover whether or not the system requirements call for such an architecture. Design-by-buzzword is a common occurrence." IMO, It's a bummer that so many ppl treat Fielding's Chapter 5 as a solution instead of an example.A METHODOLOGYI also like Fielding's approach of keeping properties, requirements (of the Web), and constraints in clear separate categories. IME, they are all needed in order to craft a clear software architectural style. Too much has been written about the last one (constraints) and not enough about the first two (system properties and requirements). I am guilty of this myself.With all that as pre-amble, my primary comment on your blog post is that I'd like to see more narration on the requirements you wish to meet (I see some of this in the final section, I think). I'd also like to see the properties that meet those requirements (I can't really identify examples of that in your blog post right now). Finally, I'd like to see a list of constraints to adopt in order to induce the properties that meet the requirements.A RANTIMO, after so many years of what I loving call the "UC Irvine School of Software Architecture" or maybe the "Taylor School", I am disappointed that not more ppl talk about the general approach of identifying and implementing "named styles." With luminaries such as Rohit Kahre, Roy Fielding, Justin Erenkrantz (to name just a few of the recognized folks), Taylor's approach seems to incubate some incredible thinking in the field of software architecture that we can all (I think) learn from and consider emulating.I think this is a good start, but much more can be done to identify the desired properties and selected constraints that would result in an arch style that matches a set of clear requirements. Let's see more!Cheers.mamundOn Thu, May 2, 2013 at 7:24 AM, 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.
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!
PS: sorry for those also following the "API-Craft" mailing list, but the topic is right at the crossing of both communities.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
- 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