Re: How much REST should your Web API get?

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
>
>
>
>