earth2marsh + hateoas   18

API Design: A New Model for Pragmatic REST | Apigee Blog
the one in which Brian links to my hypermedia tag on pinboard…
self  hypermedia  hateoas  apigee  pragmatic  rest  apis  design 
september 2013 by earth2marsh
mnot’s blog: Five Reasons to Considering Linking in Your HTTP APIs
via mnot’s blog http://www.mnot.net/blog/ There’s been a lot of interest in and effort expended upon “hypermedia APIs” recently. However, I see a fair amount of resistance to it from developers and ops folks, because the pragmatic benefits aren’t often clear.  This is as it...
iftttFeedly  hypermedia  HATEOAS  APIs 
june 2013 by earth2marsh
Peter Williams - Versioning REST Web Services
"http://foo.example/api/v1/accounts/3
I really hate this approach as it implies that an account in one version of the API is really a different resource than the account in a different version of the API.

It also forces clients into a nasty choice, either support multiple versions of the API simultaneously or break one of the core constrains of REST. For example, say a client exists for the v1 API that saves references (URIs that include the version indicator) to accounts. Some time later the client is updated to support the new version of the API. In this situation the The client can support both versions of the API simultaneously because all the previously stored URIs point at the old version of the API or it has to mung all the URIs it has stored to the point at the new API. Munging all the URIS breaks the HATEOAS constraint of REST and supporting multiple versions of the API is a maintenance nightmare."
versioning  webservices  http  rest  api  apis  design  hateoas 
january 2013 by earth2marsh
Versioning is an anti-pattern - more info
"The heart of this problem is pretty clear: We see versioning as a tool
for managing change. We'd like to change our service and break as few
clients as possible. Versioning is only one way to manage change,
though... and my contention is that it's not appropriate for
hypermedia services."
api  rest  versioning  apis  hateoas  hypermedia  stephen_klabnik 
march 2012 by earth2marsh
Guidance/Patterns/Standards for Hypermedia vs. URL Construction? - Google Groups
"Regarding HATEOS ...

If you create an API and document the URLs in the style of Twitter (https://dev.twitter.com/docs/api) and many others then HATEOS becomes irrelevant. Why? Because you have, up front, instructed the client about any and all URLs it will need. There is nothing left to discover at runtime.

If you create a media-type then there is no way for you to inform the client about the URLs up front. Take for instance the ATOM media-type (application/atom+xml) - you will find lots of link-relations in it, but not a single word about specific URLs. Now everything has to be discovered at runtime. That's when you need HATOES - its an absolute necessity when working with media-types.

By creating a media-type with associated link-rels you decouple application semantics and URL structure completely. A media-type allows you to reuse your application on other systems and servers. HATEOS is not just about adding flexibility to a specific API - it is about being able to reuse the application in completely different places. You cannot do that with the Twitter API - but you can do it with ATOM and other media-types.

As Eric Wilde wrote on Twitter: "new #REST rule: no, you cannot play with your URIs until you have designed all of your media and link relation types."

/Jørn"
hateoas  apis  rest  hypermedia  links  atom 
march 2012 by earth2marsh
REST Design Philosophies « The Amiable API
"Pragmatists believe that design trade-offs should be resolved based on concrete, project-specific requirements and constraints. They view the indiscriminate application of the same design patterns to widely different problems as a sign of dogmatic thinking, not as disciplined design. Absent specific requirements and constraints, pragmatists prefer to use the simplest possible design. What “simplest” means is again very context dependent. It may mean a design which fits the technologies, frameworks, or tools used the best.
You might argue that Pragmatic REST is not a separate design philosophy since its practitioners freely borrow and mix design approaches from all the other schools. The “pragmatic” label best describes APIs which do not fit neatly into any of the other categories. There are quite a few of these. If you look at the collection of the Google APIs you will discover characteristics of Hypermedia APIs, Data APIs, and Web APIs, but not in their purest forms."
rest  apis  pragmatic  philosophy  hateoas  hypermedia 
march 2012 by earth2marsh
Haters gonna HATEOAS—Timeless
from Pinboard Network RSS Improver http://pipes.yahoo.com/pipes/pipe.info?_id=b22b9c9acee5906aab7e8a7645a247a9 Now, when I said ‘nobody’ does this, what I meant was ‘for APIs.’ This is exactly how the Web works. Think about it. You start off on the homepage. That’s the only URL you have to know. From there, a bunch of links point you towards each state that you can reach from there. People would consider it ludicrous if they had to remember a dozen URLs to navigate a website, so why do we expect the consumers of our APIs to do so as well?Source: http://pinboard.in/
iftttGR  architecture  rest  api  hateoas  maturity  design  apis 
february 2012 by earth2marsh
rest - RESTful api design, HATEOAS and resource discovery - Stack Overflow
"Let's say I want to design RESTful api for finding cities by zip codes. I come up with resources called 'cities' nested into zip codes, so that GET on http://api.addressbook.com/zip_codes/02125/cities returns document containing, say, two records which represent Dorchester and Boston.

My question is: how such url can be discovered through HATEOAS? It's probably impractical to expose index of all ~40K zip codes under http://api.addressbook.com/zip_codes. Even if it's not a problem to have 40K item index, remember that I've made this example up and there are collections of much greater magnitude out there.

So essentially, I would want to expose not link, but link template, rather, like this: http://api.addressbook.com/zip_codes/{:zip_code}/cities, and that goes against principles and relies on out-of-band knowledge possessed by a client.

Problem 2

Let's say I want to expose cities index with certain filtering capabilities:

GET on http://api.addressbook.com/cities?name=X would return only cities with names matching X.

GET on http://api.addressbook.com/cities?min_population=Y would only return cities with population equal or greater than Y.

Of course these two filters can be used together: http://api.addressbook.com/cities?name=X&min_population=Y.

Here I'd like to expose not only url, but also these two possible query options and the fact that they can be combined. This seems to be simply impossible without client's out-of-band knowledge of semantics of those filters and principles behind combining them into dynamic URLs.

So how principles behind HATEOAS can help making such trivial API really RESTful?"
hateoas  rest  restful  apis  problems 
february 2012 by earth2marsh
The API is Dead! Long Live the API! | ZapThink
"What so many techies lose sight of is the fact that REST isn’t supposed to make the Web more like system integration; it’s meant to make system integration more like the Web. When you click a link in a Web page, you expect to go to another Web page, or perhaps a video or sound file or some other media representation. REST takes that simple interaction and abstracts it. Now you have an abstracted client (instead of a browser) supporting a request of a resource (the Web server capability, for example, the php script that generated the response) on an abstracted server (the Web server) that returns a representation (the resulting media file or Web page) as per the uniform interface (what the link you clicked was supposed to do). These abstractions let us apply simple Web behavior to all manner of system-to-system interactions. But never, ever lose sight of the fact that you want simple Web behavior from your application."
rest  apis  hateoas 
january 2012 by earth2marsh
The Right End of REST | ZapThink
"To illustrate the agility levels for distributed hypermedia applications that should frame your Agility Model, let’s work through some concrete examples. As you go through these levels, compare them to the Richardson model.

Level 1: Static hypermedia application, consisting of a set of static Web pages containing nothing but HTML, interconnected by links. Not particularly agile. Is it REST? Yes, but in a very simplistic way. Does it meet your requirements? Probably not. (Level 1 is good enough for our ZapFlashes, however, in case you hadn’t noticed.)
Level 2: Hypermedia application consisting of static Web pages that contain HTML and client-side JavaScript (no funky Ajax or the like). Pages link to each other, and the links may be dynamic, based upon client-side logic in the JavaScript.
Level 3: Hypermedia application consisting of dynamic Web pages built on the fly on the Web server, using php or Java Server Pages or whatever server scripting environment floats your boat. Pages link to each other, but the links may be dynamic, based upon server-side logic.
Level 4: Hypermedia application consisting of a set of dynamic representations that conform to a variety of media types (HTML documents, XML documents, images, video, you name it), where those representations have links to other representations, and furthermore, the links may be dynamic, based upon client-side or server-side logic or both, as appropriate."
rest  apis  hateoas  rpc  agility 
january 2012 by earth2marsh
Richardson Maturity Model
From zapthink "HATEOAS is at the highest level of maturity, and it’s perfectly fine to start at the lower levels and work your way up" plus a nice explanation of HATEOAS
architecture  rest  programming  webdev  maturity  apis  hateoas 
january 2012 by earth2marsh
APIs are a Pain
APIs are a Pain . I have seen the sneak preview and it is some amazing innovation by @sallamar & team @ #eBay
api  apis  client  rest  pain  design  Ebay  hateoas  from delicious
november 2011 by earth2marsh

Copy this bookmark:



description:


tags: