Extraverted Introverts

A talk about lightbulbs, Carl Jung, APIs, Enterprises, HATEOEWRA, the future and some other relevant stuff

June 1st 2013 Madrid, APIDAYS MEDITERRANEA

But first

Personally I am not a morning person

... did you guys

GET /coffee

Who's talking?

Hello, my name is Ori Pekelman. I am OriPekelman everywhere (twitter/github/linked-in).

My blog is on http://blog.constellationmatrix.com

I am an entrepreneur and an independent software architect and I made myself a nice logo.

The poster children for APIs, the likes of Stripe or Twilio, Twitter, Google, Sendgrid, Amazon or Facebook are not the subject of this talk.

Required reading : yesterdays talk by @guillaumebalas

This talk is not about companies whose main line of business is, can or should be expressed as an API. This is not about Internet centric businesses.

Still, we are here because of the internets.

And the internets are an amazing thing. While preparing this talk I discovered that the search for "Kline Bottle Opener" gives as a result a Kline Bottle Opener. Which exists!

Here it is.

The future of Enterprise APIs

A lot has been said about the API economy. But the "open" singularity has not yet happened. We are still in a time where APIs are frontiers for companies.

They represent the limes, where one ends and the other starts. Hand crafted projects that allow a select few to access a handful of "strategic" resources exposed by a company. A rare thing.

But this is a transitory stage. What happens when everything in a company becomes an API that can at any moment as a business decision, and not as a technical project can be opened up (internally, to select partners, to all...)?

What happens when you are able to expose data and functionality from your CRM or financial system? But also when you can expose the mean coffee consumption of your development team, or the control of your heating system?

This may seem scary and weird. Why the hell would a company want to open up its inner most secrets? Give someone control over its heating?

Well, an API connected to your lightbulbs and heating will probably allow you to gather some incredibly useful data.

They say Philips have a nice API. But if you could expose it ... maybe there will be a company out there with more data then you, better algorithmes than can save you a sh*tload of money spent on energy. And maybe it will be cheap to integrate.

In my talk I will posit this transformation will happen in the medium future, and that it will have a deep transformative effect on the way we do business.

What is an API?

Application programming interface

It is a system that allows a program to expose functionality and data to another program.

What makes a good API?

1. it is abstract: requires minimal knowledge about the implementation of the program exposed

What makes a good API?

1. it is standard: imposes the absolute minimum client side dependencies

What makes a good API?

1. it is general: it makes minimal assumptions on the way it is going to be used

What makes a good API?

1. it is simple: it allows to implement very quickly the most common use-cases (sometimes orthogonal to generality)

What makes a good API?

1. it is self-describing: it requires only minimal documentation

What makes a good API?

1. it is predictable: it does not surprise the user and it adheres to common patterns and conventions

• REST is a pragamtic style for making APIs
• That promotes "good APIs"

Applying a style is what we call the "design process"

So... Whats is a resource?

• Something that can be uniquely addressed.
• And something that can be addressed, can be addressed by a url.

How do REST urls look like?

REST urls look like just normal urls

http://www.w3.org is a good one. Also http://pekelman.com/time or http://pekelman.com/time.json or https://github.com/OriPekelman/paris-rb-grape-talk/commits/master

I will get back to this

But they usually look like:

• http://api.example.com/{resource_type}/{resource_id}.{output_format}?{filters..and..api_key..as..arguments}

or

• http://api.example.com/{collection}/{item}/{collection}/{item}/{sub_resource}

or something like

• http://api.example.com/{ver}/{lang}/{resource_type}/{resource_id}.{output_format}

So what is hypermedia?

We have seen that "REST urls are just urls" well a hypermedia API is just a REST API with links. And even more down to earth.. a REST api with elements that have a "href" can be considered hypermedia

LET'S first prove Hypermedia APIs are great!

http://almostobsolete.net/talks/hypermedia/#8

(edit: so if you weren't there, please click on the link.. see slides 8--21 then use the back button of your browser)

Interoperable presentation software!

I am using impress.js he is using reveal.js or something. I don't even need to know.

Hypermedia APIs are great because the web is

We got back to where we were. Because we had a URL! We are only doing idempotent stuff so we are at the same state.

BTW the bit of presentation you saw was by Thomas Parslow

So what is standardized this far?

Not much, for example while researching this presentation I just realized people should probably put sitemap.xml as well as robots.txt files at the root of their API endpoint. really cheap discovery. But I am not sure.

So.. this is not enteprise grade!

If even in a conference on APIs we can't get a straight answer about what are the good practices for discovery.

This is only very partially true. But let's play with getting our stack more enterpise oriented.

What should be the design process?

For Consuming exposing, reexposing hundreds of APIS over a decade.

... and the dream of COBOL

(COmmon Business Oriented Language)

or APIS for the Excel user... Can we, should we believe this is the end game?.. let's play.

Acronyms are good, they make you look serious

If it has an acronym it is a "thing"

Roll the drums...

Introducing

ERA : Enterprise RESTful APIs

Now instead of charging 10,000€ let's charge 10,000,00€ and be over with it.

ERA, this is good, still this is a single acronym.

Single acronyms are a concept.

Not an enterpise ready technology which can be sold for 10 mil.

ESB : Era Service Bus

ESB : Era Service Bus

Oh holy fork that one is taken

OLÉ

Orchestration Layer for ERA

RIME

Restful Identity Management in the Enterprise

REQUIEM

Resource Enabled Queue Interchange Enterprisingly Managed

THISSUCKS

Thin Integrated Service Support and Universal Compatability and Knowledge System

Don't worry sir, this is automagical clickety-click we know code is a bad bad thing, no code necessary, we have a lean enterprise service bus.

These layers can be one of two things: standards driven or implementation driven.

Premature standardization will be the death of the promise of this stack, this approach ... so let's not try, and if you really believe you are missing "enterprise features":

1. Verify these are real needs and not a pavlovian response to seeing a software system
2. Use one of the great vendors around here...

No magic, but we can afford it

For the moment...

Someone is going to be doing some coding...

But

This is relatively very cheap code. This is thin glue code

If you are going to be hanging around people doing presentations about REST style APIs you are going to hear this word a lot. Affordance. So as a public service:

Affordance: The stuff you can do with an object.

And in ergonomics: The stuff an object tells you, you could do with it.

That was acronym bender there. Let's also use an existing one, which is incidentally, probably the worst ever acronym invented

HATEOAS

HATEOAS (Hypermedia as the Engine of Application State)

HATEOAS

Personally I just pronounce this as Hate Us

HATEOEWRA : HATEOAS as the engine of enterprise wide REST APIs

We could pronounce this as Ha-Torah (well you need Hebrew for this pun, it sounds like the hebrew word for "The Bible")

If you put in links you are making your system, not magically, but cheaply interoperable. Ad-hoc solutions. Later in life there will be standards. You will even be able to magically autoupdate to those... how?

1. Meaningful 404s
2. DNS and 30x redirections! ---

Ha-Torah will take a lot of the pain away. But you are still going to be left with two really hard unresolved issues.

I. Authorization - how do you handle cross system/frontier rights management.

II. Search - search is hard because of the authorization issue.

lets create together an API for a lightbulb

1. What are the resources?
2. More importantly what are the linked resources?

/status

ON/OFF

Useful but not a lot of magic or fun around here..

/location

{
    href="http://offices.myhugecompany.com/paris/center/possoniere/3rd_floor/office/2/2"
}

OH yippi. This is nice. I think I understand this one. If ever there will be standard of describing offices, we can very well adhere to it.

But even more probably instead of trying to have the whole world agree on these details, I can see a company living off bridging just this..

Or maybe, just maybe one day the semantic thing will work... and then poof!