
The API-ization of everything - TheMakeA
http://blog.garrytan.com/the-api-ization-of-everything
======
bmelton
The final sentence in the article really struck a chord with me...

> Where there is paper to push, a call to answer, or a purchase to approve,
> there is an API coming to replace it.

I've made a pretty decent living in life by following the old mantra that
anywhere you see an Excel spreadsheet being used in a business process,
there's an opportunity to exploit.

That idiom has now moved even further, at this point, and I don't know why I'm
surprised to read in print what I think we've all probably intuited for some
time now.

I've been attempting to embrace this for awhile, but I think it hit home the
most last week, when I saw Joshua Beckman's article on a Personal API, and
then started building one for everybody else[1].

It's been a fairly profound experience, and every subtle feature that I add,
the more certain I am that it's the right path to be taking. Around every
turn, I think of a new use case, or a new way to extend it, or a new type of
service to integrate with -- and it baffles me that it takes us so long to
make switches in thinking like this, even though we literally do it all the
time as technologists.

[1] - I shouldn't be sharing the link, as the code isn't done, and it's likely
to set your house on fire, but because it's relevant, the Personal API service
is at [http://personable.me](http://personable.me). If you use it and it gives
you herpes or something, shoot me an email (contact in my profile) and let me
know. If it doesn't give you herpes, you can let me know that too.

~~~
pdkl95
This is a very interesting idea - a formalized representation of contact
information would help a lot in fighting the walled-garden effect of
Facebook/etc.

Unfortunately, as currently implemented, this seems to be yet another
centralized service that that is a single point of failure.

Would you consider taking a moment to write up a (draft) _protocol_ first?
Core features of the internet (representation of personal metadata could
easily count a a "core feature") became popular because the protocol was there
first in the RFCs for anybody to implement and interface with.

Link your RFC describing the protocol on the front page, and many people will
jump on it. Without that, it's just a service that could fail. (I'll never
understand why business choose to rely on services without first establishing
a /second source/)

~~~
bmelton
Admittedly, I was in something of a rush to throw it together, and altogether
skipped that step. As you'd expect, the result was a bunch of second guessing,
and false starts.

That said, I'm absolutely trending that direction, but I felt like there was
enough that I didn't know that attempting a spec out of the gate would have
led to a bad spec _and_ a bad implementation, and the way that I've always
worked, it's easier for me to spot errors in implementation that I don't catch
in a design phase, which is frustrating for both me and some of the product
managers I've worked with.

What I can tell you in the meantime is that the source, sloppy and unworked as
it is, is currently available on Github @ github.com/bmelton/personable, and
that some form of a specification is forthcoming, at least in a solid draft
state.

The thing that's been really bugging me though is that, my best guess is that
in order for it to work as I envision, it would have to be implemented as an
oAuth provider (think oAuth, but with a bunch of extra_data fields) which, at
least initially, felt very out of scope for the project, but is now starting
to feel like more and more of a necessity in getting adoption rates greater
than I'd expect to see from an altogether new thing.

EdiT: P.S. Sincerely, thanks for the feedback.

~~~
feralmoan
Did you take a look at FOAF project or similar (or the whole semantic web
ecosystem I guesS), its a good place to start for defining an ontology.

~~~
bmelton
I did, but I really see this as closer to 'finger'... perhaps even
indistinguishable from it at this early stage. FOAF has been around awhile
(tho obviously not as long as finger), and I've just never seen anybody use
it, or was blind to it when I saw it.

I definitely see some kind of 'friend' association with Personable in the
future, but it's _not_ a social network, so I'm totally vague on how those
associations might work.

------
drblast
If only this were more true. API's for most things are...lacking.

A dearth of API's is particularly bad in computer security.

Vendors: We have this great new device to monitor ___ and alert on it!

Customers: We'd like to integrate that with our other devices, and this Hadoop
cluster...

Vendors: We integrate with all kinds of stuff!

Customers: Can you show me?

Vendors: You just go to our shitty web front end and click "export." You can
get an Excel file or .csv. It's THAT simple! Or I think in the next version we
can export to syslog. Larry? Do you know about the syslog thing? Yeah, it's
going to do that. We have our engineer working on it.

Customers: Can I query the data directly?

Vendors: Sure! Just go to the web front end and arrange your Boolean logic
operations with this impossibly obtuse drag-and-drop graphical programming
hack we came up with. Focus groups LOVE it, because you don't have to type to
use it.

Customers: What if I want the machines to talk together and query each other
without me having to type in a password and click the shitty web front end?

Vendors: _crickets_ ... So how many do you want to buy?

Are you listening, potential YC candidates?

By the way, when you write software, write the API _first_ , then write your
cool UI using the API. Yeah, it's a little more difficult at first, but you'll
save untold amounts of time in the long run and the product will be better for
it.

Edit: In case this wasn't clear, I'm talking to you, you HN-reading recent
college-grad who wants to start a company but needs a good idea that doesn't
involve social networking. Make network security products with great API's and
sell them to companies. Forget about the cheesy front-end, make it easy to get
data into and out of. Your target audience is techies who aren't baffled by
databases and are willing to spend a month hacking on a system if it helps
them query huge amounts of data quickly. Also, you want to charge less than
the cost of these techies making the system themselves. Go.

~~~
patio11
I'm all for right-out-of-college HN readers disrupting schlerotic industries
that actually matter rather than making photosharing apps, but careful,
enterprise sales looks like enterprise sales for a reason. The reason is
typically because enterprise sales is the key to enterprise purchasing
departments' lock. You'd like to think that technological superiority and
sincerity will let you steal Cheesy McClueless's ten quarterly sales, but
sadly, product quality does not necessarily win out.

~~~
drblast
You don't have to sell to only large companies. I'm sure a lot of smaller
companies would appreciate a security product that could grow with them.

And are the odds of success at trying to sell products to businesses any less
than trying to create the next Instagram? Seems like a lot of people are
focused on the latter. If you're going to do something risky, go for broke.
:-)

------
dalek_cannes
Unix had this right decades ago, in the form of text-in-text-out commands,
pipes in between + text-based terminals in between machines. OS's like Windows
broke that. It's good to see the philosophy returning. As long as everything
is represented as structured text!

And an side: API's should not be patentable or copyrightable, no more than a
language is. Because that's exactly what API's are. Common languages for
machines to speak to each other.

------
zzen
For consumers, "there's an app for that".

For businesses, "there's an API for that".

~~~
jmduke
I'd follow that with:

 _For tech businesses, "there's an API for that".

For 90% of the other businesses, "what's an API?"_

There's a vast amount of value to be captured by adding pleasant and easily
used interfaces over otherwise boring APIs.

~~~
AznHisoka
For 90% of other businesses, there's an Excel export. There's your API.

~~~
antsar
Excel export to printer to fax machine, in some cases.

~~~
patio11
Someone literally requested this as an import option for Appointment Reminder,
because it was easier for their office staff to understand than uploading.

~~~
AznHisoka
I thought they wanted to download the Googles to their printer.

~~~
antsar
Well, its a two-way process. Upload to the Googles through the fax machine,
download the Googles through the printer.

------
taude
We built a product that we built about 7 years ago using SOAP web services. We
built a large front-end (something like 500 screens) in Adobe Flex. Now, we're
rewriting it using the latest JavaScript web libraries, html, css, etc... We
wrapped the SOAP/XML service calls inside a JSON parser/interpreter...

Bottom line, it's amazing how easy it has been rebuilding the front-end when
the original app was already built from a backend API. I don't think we
purposely knew how future-proof we were making our server APIs.

Now days I thought this was an obvious choise. Even if the API is for internal
applications.

------
lxmorj
I've spent quite a bit of time working with easypost's API. If you have to
ship anything, they've got a great platform and customer support.

~~~
trey_swann
Agreed. I'm a big fan of EasyPost.

------
jsonne
This is incredibly interesting. According to some people we're looking at
unprecedented growth in the space. Right now there's roughly 9k public APIs.
By 2019 that number could be over 100,000.

The question becomes though who does the integrations? Not everyone is a
developer. The world needs plumbers for toilets and electricians for lights. I
think the future of web development looks a lot like these industries. If a
website is a house you'll hire a general contractor who will outsource to
various experts in various APIs. At least that's our take on it.

~~~
JohnDotAwesome
I think the answer to that lies in HTTP discovery protocols. I'm imagining
self-organizing applications based on the need of the user, wiring together
representations of disparate data sources into a cohesive interface.

You shouldn't have to be a dev to take advantage of the API universe. You'll
just need tools that are able to reason about the data available.

~~~
icebraining
That's the goal of the semantic web/linked data, and it already works for
simple cases. But to take advantage of that you can't be stuck in the popular
"REST-but-not-really" custom APIs; you need standard formats and protocols
(e.g. RDF/a and SPARQL) that can be queried by software that knows nothing
about that particular service.

------
GraffitiTim
I agree with the premise. However, what happens to Lob when paper and mail get
replaced by digital transactions? Netflix was able to pivot from sending
physical DVDs to streaming digital movies. Will Lob be able to pivot from
printing and mailing physical checks to sending digital money, or will they be
cut out of the market?

In general, it seems risky to build an API around something that's going to
disappear.

~~~
hcarvalhoalves
> In general, it seems risky to build an API around something that's going to
> disappear.

Why? They can clearly profit while there's a need for the service they offer.

~~~
GraffitiTim
I meant in the context of trying to build a long-term business. Netflix would
be dead in a few more years if they hadn't started doing digital streaming.

~~~
ryanhuff
You wouldnt leave a $100 bill on the ground just because it doesn't come with
a money tree. Even some non-sustainable businesses may be worth pursuing while
they are viable if the benefit/payoff far outweighs the cost/effort.

------
chenster
API is a legacy term created the time before the Internet era standing for
Application Programming Interface. Should it be called Web Service to be more
precise for API connecting over the Internet?

~~~
steveklabnik
"Web services" is pretty strongly associated with SOAP, at least in my part of
the world.

~~~
chenster
Perhaps "Web API" makes more sense.

------
jabo
Along these lines, I've been thinking of a building a business around building
APIs for small businesses. I'm thinking of local mom and pop grocery stores,
local restaurants, my dry cleaner, my car wash guy, etc. Imagine a world where
all businesses offered an API to interact with them.

~~~
jsmeaton
What would an API for a mom and pop grocery store do and who would use it?

~~~
cedias
items Stock, Location, Open Hours... All that in a phone app or on google map
?

------
jgalt212
If given a choice between building a platform or API with equal likelihood of
success--go with the platform every time. APIs sit in the background and are
rarely the star. Brands have value, and it's very hard to build a brand if you
are just the glue.

~~~
hox
Brands have value to consumers, but countless multi-billion dollar industries
lie in the glue you speak of. We do not all share the interest of fighting for
advertising eyes.

------
parauchf
Well, "enterprise" software does have APIs in the form of EDI protocols.

[http://en.wikipedia.org/wiki/Electronic_data_interchange](http://en.wikipedia.org/wiki/Electronic_data_interchange)

Admittedly they're not perfect, but "hackers" weren't the first ones to think
of automating back office processes. Most invoicing, payables, receivables
etc. happen over these protocols.

Naturally these functions will probably eventually move to REST over time as
the broader enterprise software ecosystem moves in that direction, but it's
not like wild uncharted territory.

------
prophetx10
Integrate bitcoin or litecoin with your api authentication and volume
tracking... pay as they go... less work for accounting staff, lower
receivables days outstanding, no credit card fees

------
trey_swann
Armed with APIs, developers will drive the composable enterprise

[http://gigaom.com/2013/10/12/armed-with-apis-developers-
will...](http://gigaom.com/2013/10/12/armed-with-apis-developers-will-drive-
the-composable-enterprise/)

SUMMARY: The rise of APIs as a source for web services and data means that
developers don’t have to reinvent the wheel on every feature — they can source
it from an API. This trend brings about the composable enterprise.

~~~
killme2
There's always the danger of relying on APIs that are subsequently retired
with little notice though.

~~~
josephlord
It is OK as long as you have an exit plan/alternative. If you know you can
roll your own or switch to one of a number of providers in a week or so and
that is a known risk you an can manage it.

Depending on what data you are trusting the APIs with there is also the
security risk. CirleCI have just suffered from MongoHQ's security failure in a
way that is extremely urgent and customer affecting.

------
apidoc
API's are great, but they are not the end of development.

While i develop several projects and write OpenSource apiDoc
([http://apidocjs.com](http://apidocjs.com)) i see the advantages of API's
like you did it. Clean way of development and access, but on the other side
some double work on frontend and backend (for own Applications).

Iam excited of the next evolution step of API's or what will be used after
API's.

------
gnur
What I would really like is 1 api format that is uniform. This would end the
wild growth of libraries for languages, you could import a single module that
would be a universal API resolver. Just point it to the url and all methods
can be magically used. Would be really nice if you could explore the api like
this as well.. A man can dream.

------
hershel
I wonder, where is the api-zation of CS research ? It would have been nice if
CS research was available as source code, but until that happens(probably long
into the future),why aren't we seeing more research offered as API , even for
fee ?

And is it something tat can be solved by tools ?

~~~
kd0amg
A lot of CS research really does not lend itself well to being implemented as
a web-based service. A new disk scheduling policy would have all of its
performance advantage blown away by network latency. A new load speculation
technique would be an even worse for that format. A new static analysis is
likely to be far too compute-intensive to be offered to the public on hardware
the research group has the time/money to operate. It would also have to be
reimplemented for whatever languages the users care about analyzing, which
research funding agencies would not be thrilled about paying for (it's not
research). A new complexity proof probably doesn't even have exportable
functionality.

Could you point to some particular work that you would like to see APIzed?

~~~
hershel
>> A new static analysis is likely to be far too compute-intensive to be
offered to the public on hardware the research group has the time/money to
operate.

Let's describe the division between Academics and users:

Academics get a cloud based service platform, where academics install the
software which is usable by API/library[1] calls , automatically(or manually
by users) scalable , with automatic billing where X percent goes to academics.

If you're a user you can also use the platform to build your own software ,
you can easily call the academic's API/library , and you both can share
databases and file-systems.

I can even see possibility to require that academic and user code reside on
the same machine on a different VM's when disk access speed is critical.

I can imagine this working in the static analysis example, and plenty other
examples, just enter "python library" into google scholar, half the stuff
there look usable in this form on first look.

The trick would be of course to make it so easy for a academic to share his
code in this form , so that this would be the default way of working. Than
we'll get some interesting stuff, some of it production systems and some of it
just prototypes.

But even if we are talking about tons of amazing prototypes , i see plenty of
value.

Does it all make sense?

[1]There are some ways of doing RPC , that are really easy to use, almost
library like.

------
miguelrochefort
Sadly, APIs are not the solution.

Web 1.0:

That guy is bright. He knows everything about the solar system. You can ask
him any question about it, and chances are that he knows the answer.

He's also quite good at explaining this stuff, and it's much more accessible
than reading these complicated books about space.

He won't listen to others, though. He only trust his books.

Web 2.0:

That girl is popular. She has so many friends, and she's always the first to
know about any gossip. Heck, that's all she does.

Tell her something, and it's quite likely that the whole school will know
about it the next day. She keeps track of every rumor in her journal, to make
sure to remember every detail.

She's a bit naive, though, and tend to believe every rumor she hears.

Web 2.5 (APIs):

That guy is serious. He doesn't play games. You want something? He'll make
sure you get it.

Don't bother calling or meeting him though, it's not worth his time. Here's a
form you can fill to let him know exactly what you want. Sure, it looks a bit
complex at first sight, but you'll get used to it. The first time is always
the most difficult. You can call his assistant if you need help filling the
form, though.

Once you hand him the form, it's a matter of hours before you get what you
asked for. He's that fast.

Web 3.0 (semantic web):

Where is everybody? That's right, they're all at the bulletin board. What is
it you ask? It's where all the cool kids hangout.

Want to let the world know something? Anything? Just pin something there. You
have to follow the rules, though. You can't just write some gibberish on a
piece of paper, you must communicate using the proper syntax, and learn to
call things by their unique names (nobody's going to take you seriously if you
make some ambiguous statements).

Once you learn the drill, though, it's fantastic. You can find ANYTHING you
want there, as long as you know how to navigate it. No need to ask anything to
anyone, no need to learn a bunch of different ways to say the same things
(it's so annoying when that other astronomy kid use different terms to
describe the same thing as the first guy I told you about). I used to be
limited by what individual people I met wanted to talk about. With that board,
there's no such limit. I can communicate anything, get there the next day and
see an answer.

"The only limit is yourself" \- Zombo.com

Conclusion:

The web 2.5 (API web) is limited by what the service let you do. You want to
do something that is outside the scope of that particular service? Too bad,
you gotta create your own company and ultimately face failure.

These services are too rigid (lack flexibility), they're opinionated and non-
standard (you have to learn every service all over again, 10 extremely similar
services will have totally different APIs and ways to call and model things),
and ultimately, you have to level-down your solution based on the limitations
of the service. It's not a proper way to live.

Sure, it's nice and all that we agreed to all communicate using voice and
ears, but we still all speak different languages, and having to learn the
language of anyone I want to talk to is painful.

We must unify semantics, not just the medium (JSON/XML). Over are the days
where you model your classes yourself.

------
agumonkey
Reminds me of Rich Hickey arguing for programmatic interfaces first then human
interfaces.

------
kamakazizuru
if only this weren't yet another PR piece for YC startups!

