HATEOAS -> Level 3 REST? - API Craft

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion HATEOAS -> Level 3 REST?
Received-SPF: neutral (google.com: 209.85.214.174 is neither permitted nor denied by best guess record for domain of m...@amundsen.com) client-ip=209.85.214.174;
MIME-Version: 1.0
In-Reply-To: <CALeNzwkmw3Soa_F4mSrz3vw6_5d6BY4GtPXV3Yy_DUuK-hV...@mail.gmail.com>
References: <78ea3380-118e-4a9e-bc00-801846587...@t2g2000pbg.googlegroups.com>
	<27749108.1392.1334507126242.JavaMail.geo-discussion-forums@pbep2>
	<CALeNzwkmw3Soa_F4mSrz3vw6_5d6BY4GtPXV3Yy_DUuK-hV...@mail.gmail.com>
Date: Tue, 17 Apr 2012 01:29:14 -0400
Message-ID: <CAPW_8m6A6i3dm9CdB76WJzqMwmsqtkQXaPN-Bd+y98FwSsm...@mail.gmail.com>
Subject: Re: HATEOAS -> Level 3 REST?
From: mca <m...@amundsen.com>
To: api-craft@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think a viable approach is to start w/ Fielding's list of REST
constraints, drop the ones that "don't make sense" for WebAPI and, if
needed, include additional constraints that WebAPI requires (but are
missing from REST).

In this way, you define a stable, general set of constraints (not
rules, more like guidelines<g>) that can apply across platforms,
frameworks, specific applications, etc.

Starting with Fielding's Constraints:
1 - Client/Server
2 - Stateless
3 - Cache
4 - Uniform Interface
  4.1 + Identification of Resources
  4.2 + Resource Representations
  4.3 + Self-Descriptive Messages
  4.4 + Hypermedia
5 - Layered System
6 - Code on Demand

Things to Drop
Seems to me WebAPI should drop items 2, 4.4, and 6.
It's possible that (since stateless is not a requirement for WebAPI),
4.3 can be dropped, too.
Is support for Cache (3) required here?
Is content-negotiation (selecting a format at runtime) a requirement (4.2)?

Things to Add
A - Well-defined URI construction rules (need more detail here, I suspect)
B - Is support for cookies (or some session identifier) required?
C - Other architectural requirements?

Just a suggestion, of course.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me




On Tue, Apr 17, 2012 at 01:01, Greg Brail <g...@apigee.com> wrote:
> I think that the idea of "levels of maturity" makes some sense as long as=
 it
> understands that we are not all progressing in a linear fashion (as Brian
> wrote) from "neanderthal" to "enlightened" or whatever.
>
> I would instead consider aspects such as:
>
> Is the API documented so that a third-party developer can use it without
> personal knowledge of the source code or the phone number of the develope=
rs?
> Is there a way to sign up and use the API, even in a limited way, via
> self-service or mostly-self-service?
> Is the API protected from invalid inputs like SQL injection and invalid
> JSON/XML?
> Is the API protected from out-of-control clients that overuse resources?
> Is the API protected from denial-of-service attacks in some way?
> Does the API appropriately use authentication?
> Does the API appropriately use encryption?
> Does the API make appropriate authorization checks and maintain a set of
> roles that make sense to its users and prevent abuse?
> Does the API allow clients to control how much data is received so that i=
t
> can efficiently serve slow devices on slow networks?
> Can the infrastructure behind the API scale to meet traffic demands?
> Can the infrastructure behind the API survive system failures and even
> failure of an entire data center?
> Does the API provide readable and well-documented error responses?
> Does the API team understand what kinds of developers will be using it?
> Is the API written in a way that those target developers will be able to =
use
> (SOAP for .NET programmers, HATEOAS for,=A0well, people who like that sor=
t of
> thing, "Pragmatically RESTful" for me personally)?
>
> I'm sure that there are more...
>
> On Sun, Apr 15, 2012 at 9:25 AM, MattM <matthewmclartys...@gmail.com> wro=
te:
>>
>> I think establishing the maturity model is a great way to approach this.
>> =A0If the audience gets Levels 1 and 2 quickly, then you don't need to s=
pend a
>> lot of time (no loss). =A0If they DON'T get it quickly, then clearly the=
y need
>> to hear it and won't be ready for HATEOAS without it.
>>
>> Does anyone else on here agree that this maturity model (that was create=
d
>> a few years ago) could use a few more levels, possibly around areas like
>> security, service levels, and other non-functional areas? =A0Could be an
>> interesting group assignment.
>>
>> Thanks, Matt
>>
>> On Saturday, 14 April 2012 08:58:13 UTC-7, Matthew Bishop wrote:
>>>
>>> Like many of you, our company struggles with both saying and
>>> understanding HATEOAS. A few months ago I had to try to explain this
>>> to a new group of staff members and I tried using "Level 3 REST"
>>> instead. I pointed to the Richardson Maturity Model at
>>> http://martinfowler.com/articles/richardsonMaturityModel.html
>>>
>>> It worked. People got what I was talking about much easier because the
>>> Level 3 was framed in reference to the other Levels.
>>>
>>> I'm no longer using the term HATEOAS but Level 3 from now on. What do
>>> you think?
>
>
>
>
> --
> Gregory Brail =A0| =A0Technology =A0| =A0Apigee
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
