There are other sets of constraints that are just as valuable and relevant and mature to certain problem domains as HATEOAS is to the web client-server model.
For example, many web APIs consumed by an iOS app maintain their own engine of app state and it's a really good and valuable thing -- just ask the Instagram crew :-) -- just because it will never make sense as HATEOAS doesn't mean the API team is less talented or the design less mature. It just means the client is the engine of app state, CATEOAS.
Sent from my iPhone
On Apr 15, 2012, at 12:25 PM, MattM <matthewmclartys...@gmail.com> wrote:
> I think establishing the maturity model is a great way to approach this. If the audience gets Levels 1 and 2 quickly, then you don't need to spend a lot of time (no loss). If they DON'T get it quickly, then clearly they 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 created a few years ago) could use a few more levels, possibly around areas like security, service levels, and other non-functional areas? Could be an interesting group assignment.
> Thanks, Matt
> On Saturday, 14 April 2012 08:58:13 UTC-7, Matthew Bishop wrote:
> It worked. People got what I was talking about much easier because the
> I'm no longer using the term HATEOAS but Level 3 from now on. What do
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.