APISpark Announces New Swagger-as-a-Service Functionality at Gluecon

Mark Boyd
May. 22 2014, 01:12PM EDT

In a lightening talk at yesterday’s Gluecon API Strategy and Practice workshop, Jérôme Louvel CEO of Restlet, announced new support for Swagger from with the API creation platform, APISpark.

“This ‘Swagger-as-a-Service’ feature lets developers generate Client SDKs, Server Skeletons based on Swagger Codegen, share their API definition in the API Commons, or generate a Swagger UI HTML file,” Louvel told ProgrammableWeb prior to the launch announcement.

APISpark is a full stack platform-as-a-service offering that helps businesses to create, host and manage their web APIs, along with the underlying data store. Since it’s initial release, it has generated funding and developer support, and has moved into version 2 of its’ product, recently releasing v2.1 which includes extensive Swagger support.

Shall We Call It SwaaS?

Swagger is a framework that helps API developers write API descriptions and, according to Louvel, “is clearly the most popular web API description project available today.”

“Swagger includes a mature specification and a lively set of code generation tools to produce not only an interactive HTML documentation, but also high-level client SDKs/libraries and server skeletons to bootstrap manual API implementations. As other languages mature such as RAML and API Blueprint, we will also add support for them in APISpark so you can import & export depending on your development workflow,” Louvel promises.

“In APISpark V2.1, any web API that you create using our visual web IDE automatically maintains and hosts an up-to-date Swagger definition. It works for manually crafted APIs as well as those generated based on a data store schema (such as a relational database, a Google Spreadsheet and a Parse or a Firebase backend).

“This support allows us to generate additional high-level client SDKs, the popular interactive Swagger HTML to embed in the developer portal and in server skeletons to bootstrap manual API implementations. Experienced developers can manually use the open source Swagger components and assemble their own API tool chain but it takes time to set up and maintain, while less tech savvy users can find this intimidating.”

Importance of Swagger for API Discoverability

As the number of APIs grows exponentially — see ProgrammableWeb’s downloadable slides for a visualization of the speed in which APIs are growing year-on-year — developers looking to add data and to incorporate services via API into their business workflows need new ways of finding out what APIs are available. Louvel sees using Swagger’s automated API descriptions as essential for API providers in helping them get their APIs noticed by potential developer-consumers.

“Being able to provide a comprehensive and high-level specification of your web API, using formats such as Swagger is key for discoverability,” Louvel says. “It lets API providers easily promote their web API into API directories such as ProgrammableWeb or API Commons, just giving a pointer to their API definition.

“Beyond directories, being able to easily publish and maintain proper API manifests will facilitate the work of robots including search engines and web API consumer tools such as POSTMAN or SoapUI.”

Extending the API Creation Workflow to API Commons

In addition to the Swagger-as-a-Service feature, APISpark has introduced an automated workflow chain to allow API creators to generate and add an API manifest to the API Commons directory.

Given the post-Google/Oracle legal environment facing API developer-consumers, Louvel sees a growing importance for API Commons in providing business certainty. In an initial appraisal of the Google/Orace court ruling, ProgrammableWeb Executive Edtor David Berlind wrote that “For decades, the efficient interoperation of pretty much everything digital (and some things analog) has involved APIs. In concluding that APIs are copyrightable, the Appellate Court sent pretty much every technology lawyer on the planet scrambling to figure out next steps.”

Berlind is so concerned by the fallout the decision will have on the API developer community that he has changed his APICon SF keynote next week into an emergency panel to discuss the impacts:

“Following the shock wave of the recent decision saying that complex APIs are in fact copyright-able, all web APIs actors need to clarify where they stand legally speaking,” Louvel explains. “The Oracle vs Google case isn't over and it seems possible that re-implementing an existing API will be considered ‘fair use’, limiting control of the API copyright owners in this regard.

“Meanwhile, API providers need to formally define the legal terms that they offer to their API consumers. They can allow them to re-implement their API and, by doing so, reduce their lock-in fears, just like most SaaS vendors offer free data export so that their customers know they can move on to alternatives, if required. 

“The API Commons initiative launched by Kin Lane and Steven Willmott offers a clear legal framework letting API providers share their API definitions using a Creative Commons or an Open Source license. Those API definitions should include at minimum the API contract (the part visible to any API consumer), but also the Data Model exposed through the API contract. Allowing reuse and forking of the API implementation itself is a different topic and depends on the business model selected, in a way similar to closed source vs open source software.

“APISpark’s recent support for API Commons facilitates the generation of the required API manifest and its publication on both the web API portal page itself, as well as the API Commons public directory. As API consumers will become more and more sensitive to the legal terms of the APIs they use to build their applications, they will be looking to a clear legal stamp telling them whether or not they might be locked in when using a given API. Being able to quickly and consistently answer this question for APIs published on the APISpark platform should be valuable to our customers on both sides of the API.”

The new API Commons integration in APISpark is already exciting some API providers and developers. Hervé Caumont is Program Manager at Terradue (a distributed computing service for Earth Sciences) and Senior Architect for the Open Geospatial Consortium’s Interoperability Program.

“We see a benefit for space agencies and industry in their current transition to cloud computing for the exploitation of Earth data. This is a move to the platform economy,” Caumont explains. “Decades of scientific data gathered from Earth observation satellites proved useful to society. But upcoming are citizen services built by an ecosystem of value-adding providers. New jobs are needed for creating these innovative apps. So, as we need trust in cloud platforms to bootstrap industry, API Commons has certainly a role to play here. APISpark has opened the way in supporting developers with using API Commons.”

Other New Features: Google Drive Spreadsheet Wrapper

APISpark has had the functionality for turning a Google Drive spreadsheet into a programmatic API in an earlier iteration, but the updated release provides more stability and easier functionality for this feature.

“In this release, we have improved the user experience in term of authentication, sheet selection, stability and documentation with a fully revised tutorial. This feature is still in preview mode, so we are looking for additional feed-back to improve it,” says Louvel.

The wrapper feature is already finding some use amongst open data publishers, and Louvel expects this market of early adopters to grow. By using APISpark, open data publishers can quickly provide programmatic access to a data source via an open web API, while also making it easier for the publishers to maintain the data in the spreadsheet.

APISpark is in public beta, and offers a free service to developers creating up to 5 web APIs, and 100,000 calls.

Mark Boyd is a ProgrammableWeb writer covering breaking news, API business strategies and models, open data, and smart cities. I can be contacted via email, on Twitter, or on Google+.

Comments

User HTML

  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.