Re: 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:
https://github.com/restlet/web-api-style
</snip>
i think this is cool and already added the repo to my watch list!

thanks for sharing.



mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen


On Thu, May 2, 2013 at 5:44 PM, Jérôme Louvel <[email protected]> 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-style
>
> Thanks,
> Jerome
>
>
>
> 2013/5/2 mike amundsen <[email protected]>
>
>> 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 IDEA
>> First, 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." [1]
>>
>> IMO, It's a bummer that so many ppl treat Fielding's Chapter 5 as a
>> solution instead of an example.
>>
>> A METHODOLOGY
>> I also like Fielding's approach of keeping properties[2], requirements
>> (of the Web)[3], and constraints[4] 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 RANT
>> IMO, after so many years of what I loving call the "UC Irvine School of
>> Software Architecture" or maybe the "Taylor School[6]", I am disappointed
>> that not more ppl talk about the general approach of identifying and
>> implementing "named styles." With luminaries such as Rohit Kahre[7], Roy
>> Fielding[8], Justin Erenkrantz[9] (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.
>>
>>
>> [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/introduction.htm
>> [2]
>> http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3
>> [3]
>> http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_1
>> [4]
>> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1
>> [5] http://www.isr.uci.edu/
>> [6] http://www.ics.uci.edu/~taylor/
>> [7] http://en.wikipedia.org/wiki/Rohit_Khare
>> [8] http://en.wikipedia.org/wiki/Roy_Fielding
>> [9] http://en.wikipedia.org/wiki/Justin_Erenkrantz
>>
>>
>> mamund
>> +1.859.757.1449
>> skype: mca.amundsen
>> http://amundsen.com/blog/
>> http://twitter.com/mamund
>> https://github.com/mamund
>> http://www.linkedin.com/in/mikeamundsen
>>
>>
>> On Thu, May 2, 2013 at 7:24 AM, jerome.louvel <[email protected]>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:
>>> http://blog.restlet.com/2013/05/02/how-much-rest-should-your-web-api-get/
>>>
>>> Interested in hearing what you think!
>>>
>>> Best regards,
>>> Jerome
>>>
>>> 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
>>>
>>>
>>>
>>>
>>
>