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. 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.
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/)
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.
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.
Seems most useful for information that changes often. Say, for example, you move around a lot and I want to know when you're in town. I could poll your API (and others like you) and see who's in town this week.
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.
Sort of responding to you and Nick Lothian (nl) at the same time, but that's the main difference I see between something like this and webfinger, is the ease of updating.
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.
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.
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.
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. :-)
“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.
Indeed. This is why there's not so many profitable software products between the few hundred $ range and the tens-of-thousands; as soon as you need signoff the cost-of-sale increases enormously.
Honestly it's not more difficult at first -- I've started doing API-first development, eschewing MVC, and it's made life easier. I highly suggest people give it a try!
Public APIs are lacking. If you are an Enterprise entity, and can pay for it, there are some very interesting and scary APIs out there. Yes, then they hire developers to actually use them. Sorry, you're not going to be as capable as a dev team in using an API, even if there was a really nice GUI. Get over it. Complexity is the new barrier to entry.
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.
Someone literally requested this as an import option for Appointment Reminder, because it was easier for their office staff to understand than uploading.
There's a massive gap between the tools that are given to [business] end customers vs the APIs. If I'm savvy enough to propose complex processes or ask nuanced questions but not savvy enough to write code against an API to get it done, I'm SOL. Expensive developer is my only real solution.
Agree that good API UIs (I realize that's two "interfaces") has a great future ahead.
and I'd counter that point with there are a ton of businesses being built on top of API's to deliver the types of products those "Other 90%" won't build themselves.
Innovation drives more innovation, the future is business being built on top of the framework these API's are laying
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.
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.
> 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."
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.
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.
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.
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.
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.
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?
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.
While this is a fun--and potentially useful--idea, can I recommend you spend some time hanging around/working for small businesses? You'll find the experience pretty useful.
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.
Don't think API, think structured data in HTML. You could get all those benefits by just convincing the web developer to properly markup that information using RDFa or similar.
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.
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.
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.
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
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.
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.
API's are great, but they are not the end of development.
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.
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.
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 ?
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?
>> 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.
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.
> 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.