API - API
'Hooks into things' - and?
If the last decade was all about open source, the next decade will be about open APIs. However, as with open source, APIs aren't necessarily a guarantee of billions in the bank. They're simply the ante for playing the technology game at scale. That scale will be determined by who gives developers the best access to data, and …
'Hooks into things' - and?
All very well and good, but the article seems to imply the only thing worth creating is a web-based service these days. The reality is, the majority of us are still writing regular software or web-apps which aren't designed for use by millions.
It might be cool and 'in', but it's still better to find a problem that needs a solution than to try and find a problem that _needs_ Hadoop and an open API.
I disagree. I have found myself implementing APIs for all internal infastructure related services for the past 4-5 years now. The reason for that is because it makes it easier to integrate all these services together, enabling much easier automation.
Not talking about web services but, as an example, F5 provide a SOAP based API to administer their load balancers. Yes, it's a web based API run on top of apache. But that doesn't matter, what matters is how you use it and the fact that just by having a web based API you have created an interface that is both cross platform and language agnostic, enabling anyone to use it.
If you write some internal service that enables a team to do something, either automation of a task or access to infastructure or something, why not make an API for that service so that other teams and, crucially, other services can leverage it however they see fit without caring about the actual implementation details, what language it's built in or OS it's running or whatever.
"This shift from open-source software to open APIs becomes ever more critical as we move to cloud services, where developers can no longer access the underlying software."
Who is "we", Kemosabe? Marketing? It sure as hell ain't software engineering ...
"The next Kingmaker" - I'll bet you that that next Google or Facebook won't be because of APIs If you think you know what the next wave is your probably wrong. Did you guess that search could make the money it does now in the late 90's? Did you think social networking would be big before MySpace, Friends - Facebook?
Fact is no one knows - and if they did, do you think they would be spilling the beans to the world?
How cute, it's like the industry just discovered the basic principles of software modularity and shared/rpc library interface design all over again.
Because all the new "engineers" enamoured with Web 2.Oh forgot the groundwork that made it all possible and went for the flashy stuff.
Now that we've all had our decade of style over substance, it just might be that people - and maybe even managers - are starting to realize that making things easier for developers is not just a fringe benefit, but can actually create new and more powerful applications.
And we're at this point because managers are not developers and haven't been paying enough attention to what their devs have been saying. After all, up to now, an API was just wasted company resources - not something worthy of being put in an attention-grabbing PowerPoint presentation.
And apparently we no longer have REST or SOAP or POX web services, we now have APIs instead.
An API is an interface applications use to do something that a platform provides. Yes, there are internal APIs restricted to a companies applications, but any platform provides "open" APIs that anyone can program to.
Windows provides Win32, COM, DirectX, .NET, and others. Linux/Open Source provides Qt/KDE, GTK+, Pango, readline, ncurses, WebKit, SDL, Cairo, OpenGL and others. Mac provides Cocoa, Carbon and others. Firefox provides XUL, JetPack and other APIs for extension developers. Chrome provides NaCL. Bugzilla provides an API for accessing its data. Flash does the same.
Major websites that provide a platform to interact with their services (Facebook, Twitter, Google). These APIs will be some form of AJAX serving XML or JSON data. How do you interact with these? Using HTTP, XML and JSON APIs provided by a framework (web browser, .NET, Qt) or a collection of libraries (libxml2, expat, curl and others).
That is, you can use the twitter API to provide a twitter feed on a Windows desktop, Windows 8 start screen, KDE plasmoid, as a Gnome Shell extension or anything else you can think of. Or write a Gnome application that triggers a notification whenever someone posts to your Facebook wall.
...is that some other bugger has control of the off switch.
Grab them by the API's (and the proprietary data formats) and their hearts and minds follow right along.
> If the last decade was all about open source, the next decade will be about open APIs
Only if you are Microsoft and are desperately tring to kill OPEN SOURCE. He who controls the open APIs controls the monoculture .. er .. ecosystem :)
It's not just APIs that need to be done in secret, but just about any solution to business problems that can't be put into MS project or something similar. If management doesn't understand the why's and how's of what gets done, and what needs to be done, they end up demanding a solution out of frustration, but often time subconsciously sabotage any attempt at resolving the issue due to their apparent need to understand that which is far above their heads, and will make the actual problem solver have a nervous breakdown form all of the imagined issues brought up by management. So yeah, if you want to solve any problem these days, you have to do it in secret, or it will never get done. The main reason I believe this is the case is because management will take full credit for solutions, and scream about taking responsibility for the mistakes of their decisions and their underlings "lack of ability" because this is a side effect of taking responsibility for something that the managers had no input in other than saying it needs to get done. Suffice it to say, when things don't go as the manager imagines, they DO NOT take responsibility, as they tend to stay employed, and their underlings either lose their jobs, or have the ever looming threat that the slightest mistake could bring down the wrath of the company, while their uncountable accomplishments are lucky to get a nod of approval, as the superhuman ability to solve problems is now the expectation.
So yeah, that's my opinion on this industry ruining topic, idiot geniuses in management positions who know and understand so little, that no matter what is accomplished, the businesses eventually fall, as their promises to the investors do not match up with their ability to manage a group of tech experts. And while the managers move on to other high paying jobs, IT professionals like myself are instantly getting less and less pay, and are expected to perform miracles on demand.
My message to them is a big FU and I honestly cannot wait for their generation to die off, I know that sounds bad, but they have made my life, and those of others, a near living hell of stress and depression, having no ladder to climb anymore, each year I find my field getting paid less and less... while what we are expected to accomplish grows...
Am I bitter, fuck yes!
@Stephen Sherry: hmm yes, get your point about doing stuff in secret. Also get your frustration re management.
But: are you sure the future generation of management will be better than the one that's dying off now...
It all depends at what level your playing and what you're delivering.
The vast bulk of software will make *use* of an API rather than developing one, so I find it hard to see why this is where the big money is at, except for a small handful of big players - most of whom haven't managed to make any money from their API's yet!
There are thousands of small to medium sized companies churning out thousands of web sites & web services that will never offer an API because they don't need to. Instead, they will hook into API's such as Google Maps or Twitter. These websites exist in niche markets that don't warrant the sharing of data services. It's a closed system.
Then there's the whole aspect of revenue streams and why a company would wish to create an API that allows other websites to use their data?
If your *paying* for that service, for using the API, sure, there's a business case - but then, it's not open.
In short, I don't see API's as being "the next big thing since Open Source" at all.
They are simply another tool in the kit.
Instead, the next big thing will be open data that doesn't require an API at all.
Data that is completely free from binding structures. Semantic, distributable across any platform or device, a set of standards much like HTML that define how data can be truly open.
OpenStack is doing it wrong by not following AWS? We tried. The problem is AWS is not open. Sure, you can use it and it is published, but it is not developed in the open. It was easy to rally around linux because developers had a voice in where the project went. With Amazon, you're stuck with however a single company wants to go.
The biggest issue we had was supporting features AWS didn't have, which meant defining our own actions in the API. The problem is if AWS then added the same feature, they would most likely do it their own way, and then we would have fragmentation. AWS has never been open for collaboration, Bezos doesn't have any love for open source or open standards. For Open
APIs to succeed, especially ones you want to become industry standards and cross organizational boundaries, you need open, extensible protocols and processes to make sure everyone can participate. That is what the OpenStack API is trying to provide.
In a perfect world, each IT system would have a nice interface such as a RESTful interface and expose its features in total to the outside world.
The little problem is, not even software developing businesses get their APIs right in most cases. Do we seriously expect a corporate developer in a non-software business to design and document a truely reusable API ? These people have a hard time with the SAP, Exchange and Oracle contraptions they already have. In addition to that, their managers are mostly comprised of the politically savvy, but intellectually challenged sort who don't even have the slightest clue about the effort just required to write a clean API specification. All they can do is write cheques to IBM, Oracle, SAP, MS and the like. This is not going to work.
I couldn't agree more with you. I've been working for years in "enterprise" applications development and it really is as far from the actual software engineering as you can get. There are factors like politics, money, lock-in etc. that influence software design and implementation which is never going to end well.
"If the last decade was all about open source... ". The last decade was actually about iphone, facebook and twitter (with a late dash by Android). For all its virtues, open source barely rates a mention.
...is all well and good, and a boon to integration; but if one does not also have an open implementation then final control still lives with the proprietary code holder who can hold the entire developer community to ransom on a whim.
In fact the whole phrase "Open API" is a misnomer that does nothing expect dilute and obscure the meaning of "open" (just as "open" did for "free"). What we have here is a nothing more than public APIs.
The increasing dependence of "Open API"s as people integrate their toilet with Twitter (or whatever banality they think people care about) merely entrenches proprietary code and companies. The F/OSS community should resist the urge to depend on "Open API"s unless they can also roll their own fully-operational implementation.
Failure to do so will leave F/OSS at the mercy of proprietary.
Maybe this is why MS are so keen to push "Open Surface" it's the same Trojan Horse, just a different jockey. Or maybe an "Open API" means one that can be invoked without patent infringement. After all, we have ISO "Standards" that can't be full implemented without begging for patent protection.
As for APIs for internal systems, whether over SOAP/JSON/XYZ (pref using open libraries for future-proofing and resilience), this is just good planning and should be part of any design process. The various layers should all have well documented APIs (and test sets for same) so that any one layer can be swapped/updated without the other layers being overly disturbed. If you can only access your CMS (say) via a single client and the CMS can only access a single database via a single connection; then you are a bloody moron.
No layer should care what the other layer is beyond the API boundary.
those that Microsoft offered to Novell and promptly hidden from them soon after that at the most convenient moment more than a decade ago ?
like for instance those published by Lmax for their customers - anyone can download protocol specification and open implementation in Java and .NET.
There are many more examples; basically it's hard to imagine business which does not do it to some degree, at least internally. API may be nothing more than specification of request and response passed via some network protocol, or it can be (and often is) client library in one or many languages for clients to use.
"Politicians may focus on ways to get consumers to spend more money in an effort to rebuild their economies"
Politicans may do so but that just means they are ignorants, can't think and don't define their words. Or they are actually "vote me in, feed me taxes and fuck you all" evil.
I think a better example should be found.
An API is nothing new, Windows has had it for decades. What is specifically being talked about are open _services_, not APIs.
Also @Brah, yes you may have been working this way but this way of working has been possible for the last 10 years using servlets/PHP/ASP, the _motivation_ to do so is all that's changed and I'm not sure how much of this is hype/fashion.
I've nothing against modularity, it's very cool... but doing it (using web-based service protocols) by default is not ideal IMHO.
"open APIs don't come with the baggage of licensing fundamentalists."
Tell that to Oracle, who are currently suing Google over their use of the Java APIs in Android. It seems that the APIs are copyrighted by Oracle and nobody else can recreate them without Oracle's blessing.
They wont win, unless the court makes a massive boo-boo, but they are trying very hard and costing Google a lot of money.
Sorry but your article is full of buzzwords and it does not actually contain too much content...
"But not just any APIs. The industry can't stomach a million competing APIs any more than it could digest a huge array of open-source projects for CMS, ERP, etc. We need APIs, but we also need standardization."
What are you talking about? How are those statement of any value at all? Companies that make software mostly want people to be locked-in to their APIs (whatever API means in your vocabulary - it's at the same level of substance as "cloud computing"...). And on top of that you have a whole industry of software integrators who implement solutions using proprietary products and there will never be any standarization as long as "managers" or other "business development" people have control over the business side of things without any knowledge of what is the right way to do things.
So please stop spreading this nonsense about new buzzword of the year or whatever, you are just bringing down the level of this website.
Biting the hand that feeds IT © 1998–2017