The API-ization of everything
blog.garrytan.com
blog.garrytan.com
> 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. 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.
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/)
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.
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.
It has the bonus of having support from places like Google:
Discovery: curl -i https://gmail.com/.well-known/host-meta
Information: curl "http://www.google.com/s2/webfinger/?q=acct%3Anick.lothian%40...
Or maybe, as a freelancer it could be used to signal that you have free time. And the consumer could then find 5 rails programmers, who also know whatever, with at least a week of free time coming up.
Further, I see a distinction between Personable (the site) and the "Personal API", is that I see Personable as also having services that actively monitor other social sites and update Personable automatically. Checkins to Foursquare, Facebook, etc could be automatically read in to Personable, which would show your 'current location' as whichever the most current update is, regardless of which provider you used.
Same thing with RSS feeds, Youtube videos, etc., etc.
Perhaps not much of a distinction, but that's my thought process anyway.
That said, I'm seeing people log in successfully. What sort of errors are you getting?
Mind shooting me an email on it? I'll make it up to you, somehow.
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.
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. :-)
“Techies” do not usually make purchase decisions. Those products that you describe sell well because the very same features you decry (Excel files, drag-and-drop web UI) are appreciated by those who actually make the purchasing decisions.
There are a lot of reasons for this - both positive & negative.
In some places the size of your budget is a measure of your importance.
In some places once you go over a manager's personal sign off authority there is no difference between asking for $50,000 and $250,000.
This sentence is enough for the upvote. I agree with the rest, too.
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.
For businesses, "there's an API for that".
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.
Agree that good API UIs (I realize that's two "interfaces") has a great future ahead.
Innovation drives more innovation, the future is business being built on top of the framework these API's are laying
I'm not bitter about Army Regulations regarding *.mil TLDs at all.
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.
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.
I certainly believe that in some cases, companies will take advantage of APIs directly. In many others, however, I think you're more likely to see new businesses built on top of APIs. These businesses will develop the applications that companies use.
A key thing to consider is that a lot of functions that the new breed of API providers seek to provide are currently bundled with other products/services that customers don't necessarily need.
Example: Company A might be spending $xxx/month for a service that provides X, Y and Z when it only really values Z. If an API provider can aggregate enough demand around function Z so that third parties can cost-effectively build offerings around function Z only, Company A may now have the ability to find a service that meets its needs at a lower cost.
So while I'm sure there's going to be a healthy market for developers focused on API integration, I think the bigger opportunities are around taking advantage of these APIs to create more focused, cost-effective solutions. Think of it as the software industry's equivalent of "unbundling."
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.
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.
On one hand, you may discover (as I fear) that mom-and-pop don't need an API or don't have the resources to pay for one. Perhaps even if they did, nobody would use it.
On the other, you may conveniently find yourself with the first few customers you'll need. They'll already know and trust you, and you'll have very clear idea of what their challenges are.
In fact, location is already supported by Google: https://support.google.com/webmasters/answer/146861?hl=en
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.
http://gigaom.com/2013/10/12/armed-with-apis-developers-will...
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.
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.
Yet APIs can be a great way to launch a product fast. You have to become independent as soon as you can.
While i develop several projects and write OpenSource apiDoc (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.
And is it something tat can be solved by tools ?
Could you point to some particular work that you would like to see APIzed?
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.
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.