Re: How much REST should your Web API get?

Jan:

yep - most of us are focused on getting an instance up and running. going
through the conscious work of wolking through a methodology for selecting
properties, requirements, and constraints doesn't happen. like so many
other things in life, we fall back on what we know, mental shorthand, past
experience, and rely on short-term execute/eval loops[1] to get the job
done as efficiently as possible given the time allotted.

also, Fielding points out that the abstraction of architectural styles (not
just one, but the category of all of them!) is two abstractions away from
the implementation[2] and that's one too many abstractions for most folks
to deal with.

anyway, back on point, I think Jerome makes a solid point here. My POV is
to step back (or up, if you like), ask what requirements you REALLY have
(low-barrier to entry for API devs), what properties you REALLY want to
induce (fast  build & release cycles), and what constraints you need to
impose in order to get the properties that meet the requirements
(convention over configuration constraints, etc.).

FWIW, another Q i ask clients is "what are we optimizing for?" for example
do we want to optimize first for runtime experience? user experience?
design-time experience? developer experience? governance experience? while
we may want all, what are the priorities here? (e.g. writing in assembler
can improve runtime experience, but is hell on dev experience!).


[1] http://www.it.bton.ac.uk/staff/rng/teaching/notes/NormanGulfs.html
[2] http://www.amundsen.com/blog/archives/369

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 8:18 AM, Jan Algermissen
<[email protected]>wrote:

>
> On 02.05.2013, at 13:58, mike amundsen <[email protected]> wrote:
>
> > 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.
>
> +1, well put.
>
> What continues to shock me is that the "UC Irvine School of Software
> Architecture" (building upon Garlan/Shaw and Perry/Wolf) seems to be
> completely unknown to the vast majority of people studying (and working) in
> the field of software in general. Why is that not part of software
> engineering 101 courses all over the world?
>
> The same goes for the idea of "principled design", namely that design
> decision should be driven by purpose instead of being ad-hoc. Your call for
> more detailed requirements (aka "properties of key interest") illustrates
> that.
>
>
>
> Jan
>
>
> >
>
>