earth2marsh + hateoas   25

A brief moment of RPC vs. REST.
"Here's a brief analysis of RPC vs. REST based on one person's opinion."
hypermedia  kevin_swiber  rest  rpc  hateoas  benefits  pros  cons 
april 2016 by earth2marsh
Darrel Miller on whether Hypermedia APIs will save the universe — The API Economist
Excellent overview from Darrel
"A Hypermedia API is one that returns links in the HTTP responses that a client application follows to achieve defined goals. Which link the client follows is based either on client-based algorithms or human input. Many people make the distinction between links and forms, I don't usually bother.  A form is a link with parameters that need to be filled in. If you want to sound clever you can call them affordances."
hypermedia  darrel_miller  Hateoas 
april 2016 by earth2marsh
"Quickly and easily create REST APIs for use by humans and machines.

The project allow you to:

create web based services according to RESTful constraints
aggregate / mashup multiple resource managers into a single interaction service
program Hypermedia (HATEOAS) interactions with a state machine domain specific language (DSL)"
apis  rest  hateoas  dsl 
november 2015 by earth2marsh
Measuring REST – Subbu Allamaraju
"Don’t follow models like Richardson’s Maturity Model to decide whether your app is RESTful or not.

Why not? The reason is quite simple. We build software to do something of value while accounting for some quality attributes (or "ilities"). In the case of RESTful apps, how you prioritize a given set of quality attributes can help you choose the right set of constraints. Period. Judging an app based on what REST constraints it supports and not based on whether it chose the right constraints to meet the desired quality attributes is a pointless exercise. It is like criticizing an application because it chose to use an RDBMS and not a NoSQL store without looking at the qualities that lead to that choice. It is equally silly to conclude that your RESTful app achieved the "glory of REST" with its choice to use the hypertext constraint – what matters is whether it met any ilities that matter for that app."
rest  compliance  richardson  dogma  constraints  APIs  HATEOAS 
november 2014 by earth2marsh
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 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
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 ( 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."

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 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:
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 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 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:{: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 would return only cities with names matching X.

GET on would only return cities with population equal or greater than Y.

Of course these two filters can be used together:

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: