These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.

Google And AWS APIs Available In Visual Studio And Eclipse IDEs

I'm always learning from the API pioneers, and trying to understand how they are pushing forward the API conversation. I'm neck deep in profiling AWS APIs, as well as Google APIs. One common pattern I'm seeing across both providers is the support for API access in both Visual Studio and Eclipse IDEs. 

Google is helping developers find APIs within both of the leading IDE platforms. They have long had some Eclipse plugins for their API infrastructure, but I recently noticed they also have a pretty robust solution for Visual Studio developers. The Google APIs .NET library is made available in Visual Studio using the NuGet package manager, opening up access to a significant portion of their API stack.

Amazon also provides Eclipse and Visual Studio tooling as part of their AWS toolbox. Opening up access the AWS API catalog to developers in the IDE they are are using to build their applications and craft their system integrations. I don't know how much time you've spent looking through the AWS catalog, but it can be a timesucker--giving me access to APIs in my native environment makes a lot sense.

I feel like API innovation in the IDE is right there with API integration into our continuous integration workflows, and the usage of Github. You should haven't to depend on Google to find your APIs, they should be right at your fingertips in your IDE, no matter whether they are for your applications, or for managing your API operations. All your internal, and 3rd party APIs should be baked into your development, and continuous integration environments, allowing you to orchestrate exactly the application experience, and life cycle you desire. This is just one of the fronts I'd like to see API discovery evolve in coming years, reaching developers with new APIs and paths during design and development, as well as across continuous integration stages of our work.

Azure and Office APIs in Visual Studio

I was reviewing the latest changes with Visual Studio 2017 and came across the section introducing connected services, providing a glimpse of Microsoft APIs baked into the integrated development environment (IDE). I've been pushing for more API availability in IDE's for some time now, something that is not new, with Google and SalesForce having done it for a while, but is something I haven't seen any significant movement in for a while now.

I have talked about delivering APIs in Atom using APIs.json, and have long hoped Microsoft would move forward with this in Visual Studio. All APIs should be discoverable from within any IDE, it just makes sense as a frontline for API discovery, especially when we are talking about developers. Microsoft's approach focuses on connecting developers of mobile applications, with "the first Connected Service we are providing for mobile developers enables you to connect your app to an Azure App Service backend, providing easy access to authentication, push notifications, and data storage with online/offline sync".

In the picture, you can see Office 365 APIs, but since I don't have Visual Studio I can't explore this any further. If you have any insight into these new connected services features in the IDE, please let me know your thoughts and experiences. If Microsoft was smart, all their APIs would be seamlessly integrated into Visual Studio, as well as allow developers to easily import any other API using OpenAPI, or Postman Collections. 

While I think that IDEs are still relevant to the API development life cycle I feel like maybe there is a reason IDEs haven't caught up in this area. It feels like a need that API lifecycle tooling like PostmanRestlet Client, and Stoplight are stepping up to service the area. Regardless I will keep an eye on. It seems likno-braineriner for Microsoft to make their APIs available via their own IDE products, but maybe we are headed for a different future where a new breed of tools helps us more easily integrate APIs into our applications--no code necessary.

API Discovery Continues Its Move Into The IDE With Eclipse Che

Another layer to the release of Codenvy this week, was the announcement of the Eclipse project Che, an open source "project to create a platform for SAAS developer environment that contains all of the tools, infrastructure, and processes necessary for a developer to edit, build, test, and debug an application”. Che represents the next generation IDE that runs in the cloud, which coincides with other signs I've seen around API discovery moving into the IDE with signals from API pioneers like SalesForce and Google, or from Microsoft in Visual Studio.

I’m still learning about Che, but I’m beginning to see two distinct ways Che and APIs can be employed. First lets start with the environment:

You can build extensions for Che, and when those extensions are compiled into the kernel, Che creates server-side microservices, a RESTful API, and cross-browser optimized JavaScript, which is then pluggable into a browser IDE. With Che, developers are given the pluggable structure of Eclipse, but accessible through a cloud environment.

This means you can orchestrate development workflows, with APIs. You can predefine, deploy, customize, maintain and orchestrate very modular development environment where everything can be controlled via API. What a perfect environment for orchestrating the next generation of application development.

Next I see APIs leading the development lifecycle as well, not just defining the development environment and process. Earlier stories I’ve done on API discovery via SDKs, showcase SaleForce and Google providing native discovery of their APIs directly in Eclipse. In an Eclipse Che driven development environment, you could define pre-built, or custom API stacks, bringing exactly the API resources developers will need and bake them directly into their IDE—meaning APIs find the developers, developers don’t have to find their own APIs.

This approach to API discovery via the IDE provides some various interesting opportunity for marrying with earlier thoughts I’ve had around being an API broker. I can envision a future where API evangelism evolves to a point where you don’t just represent one API, you can represent many APIs, and configure API fueled developer environments for building any type of application. Think of what Backend as a Service (BaaS) providers like Parse and Kinvey have been doing since 2011, but now think of pre-configured, or custom tailored IDE environments with exactly the resources you need.

I’m just getting started with Che, and Codenvy, so it will take me a while to work through my thoughts on using it as an API brokerage platform. The one thing you can count on me for, is that I will tell stories all along the way as I figure it out.

Disclosure: API Evangelist is an advisor to Codenvy.

Expanding The Layer Of API Discovery From Within The Developers IDE

Much like API design and integration, the world of API discovery is heating up in 2014. We are moving beyond the API directory as our primary mode of API search, in favor of a distributed approach using APIs.json, and supporting open source search engines like Another area of API discovery I’ve been watching for a while, and predict will become an important layer of API discovery, will be via the Integrated Development Environment (IDE) plugin.

Open Source SalesForce API IDE Plugin
SalesForce just announced they have just open sourced their API IDE plugin on Github, after developing on it since 2007, when APEX was born. The plugin is old, but is very much in use in the SalesForce ecosystem, something I’ve written about before. They will be accepting pull requests on the main branch, looking to improve on the codebase, while looking to also maintain a community branch, as well as encouraging you to establish your own branch.

Does Your API Have An IDE Plugin?
How far along are you on your own APIs Eclipse Plugin? Are you trying to reach enterprise developers with your API resource? You should probably look at the pros and cons of providing your API developers with a plugin, for leading IDEs. With the open sourcing of SalesForce API IDE plugin, you can reverse engineer their approach and see what you can use for your own APIs IDE plugin—smells like a good opportunity to me.

Opportunity For General Or Niche API IDE Plugins
Not that using SalesForce open source IDE would be the place to start for this kind of project, but I think there is a huge opportunity to develop API focused IDE plugins, for top developed environments, across many popular APIs. Developers shouldn’t have to leave their development environments to find the resources they need, they should be able to have quick access to the APIs they depend on te most, and discover new API resources right from their local environment, aking IDE plugins an excellent API discovery opportunity.

Native Opportunities For IDE Platforms
I’ve seen a lot of new development environments emerge, many are web-based, with varying degrees of being “integrated”. I think that IDE developers can take a lead from Backend as a Service (BaaS) providers and build in the ability to define an integrated stack of API resources, right into a developer's web, mobile, or Iot development environment. If you are building a platform for developers to produce code, you should begin baking in API discovery and integration directly into your environment.

All I do as the API Evangelist, is shed light on what API pioneers like SalesForce are up to, and expand on their ideas, using my knowledge of the industry--resulting in these stories. SalesForce has been doing APIs for 14 years now, and the IDE has been part of their API driven ecosystem for the last seven years. I think their move to open source the technology, is an opportunity for the wider API space to run with, by helping improve the community SalesForce API IDE plugin, but also apply their experience, and legacy code to help evolve and improve on this layer of API discovery, available within the IDE.

If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.