Hello, Charles. Thanks for having me. I am a web API expert and I am a big fan of REST for many years now; and I am also an entrepreneur - I am running a start-up, Restlet, as well.
2. Why did you create Restlet?
I created a framework in 2005. I created it because I was looking for a solution to build a proper web application, for an easier REST architectural style and there was no solution there at this time for Java; so I decided to create one and to open source this project. That was the start. Then I got some nice feedback from REST, people looking for REST solutions, and I started to add features and to make it a more stable framework, and through time the community grew around this framework, so I decided to create a company to support the research and development and the community basically, a few years after. That was the origin of the framework.
3. Right. How does Java compare to other languages with regards building RESTful applications?
I think Java is... A lot of developers obviously know Java and it is a good language in terms of scalability, in terms of productivity to build web APIs. So I think it is a really good fit; you have a lot of very advanced scalable IO libraries, frameworks like Jetty and Netty and so on. It is really easy and effective to build scalable and highly available web APIs. I think it is a perfect technology for web API in general.
Many frameworks are based on the JAX-RS standard for Java APIs, but a few of the frameworks are trying to have a different approach in terms of trying to provide different Java APIs to build or consume a REST API. So initially when the Restlet framework was created there was no JAX-RS standard at this point. So now we have added support for JAX-RS, but we have our own Restlet API, and in terms of comparison I would say that this API has a broader feature scope. We unify the client side and server side Java API, and in terms of coverage, we have support for virtual hosting, routing, featuring, web security. Everything is really integrated into a core set of Java classes and it is very extendable as well, and very flexible. So, I think yes, some development in terms of type, the Restlet API compared to the JAX-RS API so, that is one differentiator that we have. And the framework is now part of a broader platform, the Restlet platform. I talk more about the APISpark Platform-as-a-Service, and we have a new project coming out – the Restlet Studio, as well, so we try to cover the full life cycle of a web API project, and not only focus on the pure implementation of the web API.
Charles: That is interesting. Tell me a bit more about Restlet Studio.
Restlet Studio is a new product. It is a pure web-based IDE for APIs. It can run in Chrome or in any modern web browser, and basically it lets you design, craft the contract of your web API very visually. So, you define your endpoints, your resources, your HTTP methods and you define for each of them the parameters and everything that makes your API contract. And from that visual definition we generate automatically the Swagger or the RAML source code, the equivalent source code, and you can switch between tabs like you would do in a typical IDE between the XML Design View and the actual code view of your XML. So that is the same approach and on top of that, we can generate client SDKs and server skeletons based on these API definitions. So, that is the start. It is the first preview version of the Studio and it is free, there is no log-in, you can directly use it in your browser and we plan to extend and add a couple more features based on the feedback from the community.
5. Great. So, what else is on the roadmap for Restlet?
Restlet - there is a third product, the APISpark Platform-as-a-Service for web API – so it is really the first platform to cover the full life cycle of a web API project: from the creation to the hosting, the scaling and the consumption of service web APIs. Everything can be done from a simple web browser, so we focus a lot on APISpark and trying to make a connection between each user product. So for a developer who has already implemented his web API in Java, in Restlet or in Jersey or in any user framework, providing a way to introspect extract the contract of his web API, and from that contract move it to APISpark so he has access to a very visual interactive documentation for the API, always up to date.
So he can sync between the source code of his API and the actual contract of the API, in APISpark, and share this contract with other developers on the team, with partners, with the consumer of the web API; and from that, we provide management features for this API. So, it is very easy coming on to add a firewall to your web API and control it from APISpark, as well as do some user management and other API management features. So that is one way to use APISpark, in combination with a framework. The other way is to say, “I’ve got some data I’d like to export and expose as a web API, and then I need a solution to host my data and explore the API and host the API as well”. So APISpark really does the full-stack approach to web APIs. So these are two ways to use a platform.
6. OK. So, it is essentially a PaaS for building and hosting web APIs: is that correct?
Exactly. We cover everything, definitely, including the hosting and the scaling of the API. So if a company does not have the time or the resources to host, secure and scale a web API, it can use APISpark to achieve that in a very time- and cost-efficient way. Obviously we don’t own the machine, we run on top of Amazon Web Services, but on top of that we provide all the life cycle management of a web API, versioning the state of the API from the draft state to the published state, including the deprecation and archiving of the web API. So, it is very easy for an API consumer to know that their API won’t break and they have a clear path to upgrade to new versions. And the same for an API provider: it’s easier to manage and govern a set of APIs.
7. Do you offer anything with regards promoting an API that I am releasing?
We started to create some support for promotion. Today we offer an export of an API commands manifest. So, based on your contract, your API contract, with a set of additional metadata - that is a copyright, a license, et cetera - we provide a proper manifest for API commands that you can push to API commands; and we are working on integration so they can directly push it to API commands through their own API.
8. What does the platform offer with regards the Swagger Spec?
We are part of the Swagger 2.0 working group. I think it is a great evolution in terms of the definition of a web API; and what I like a lot in the Swagger community, is the fact that it is not only a specification, but it is a set of tools to produce client SDKs and server skeletons and so on, with a lot of contribution from various developers in various programming languages; so you get very good support for, I don’t know, PHP and Java, Objective C and so on, because these client SDKs are maintained by experts in that field. So we definitely support the Swagger community and project and we embed Swagger in APISpark, in a Swagger-as-a-Service way. So, it is very easy to use the toolchain, the Swagger toolchain, and we integrate Swagger as well in the Restlet framework, so it is very easy to introspect the Restlet API application and to extract a Swagger contract and to display the Swagger as an interactive Swagger UI: that is very well-known so everything is really built in, so you do not have to download and integrate all these components. But we do not only support Swagger, we support other API languages such as RAML today as well, and we plan to support more API languages moving forward.
9. Why do you think enterprises would be interested in APISpark?
I think that the main issue for enterprises is not only to create the API, but really to manage a large set of web APIs. What we see… Obviously you have the public web APIs, you have a few of them for a typical company, but you have a lot internal APIs to communicate between various departments of the same organization, to support back-ends for mobile applications for connected devices. And all these APIs need to be consistent in the way they are exposed and consumed; they need to be properly managed over time - again, the life cycle, the versioning – it is really hard to have a consistent and integrated view of all your APIs: and moving forward you will have a lot more than today. So we try to support this governance and API management platform for them.
I think that one of the main additions was the support for the client side API in JAX-RS. I think it is a good feature to have. It is not fully consistent in terms of design and annotation; it is a different design that was chosen. I think it would have been probably better to have a more consistent use of annotations on both sides of the table. But, aside from this, I think that the specification is maturing in a good way and it is offering a broader feature scope and good integration with the rest of the Java EE platform in general. So that is good.
11. What are some of the more interesting implementations of Restlet that you have encountered?
Since 2005 we have seen a lot of usages of the Restlet framework, from start-ups to big corporations and government agencies. Start-ups like RunMyProcess building Platform-as-a-Service for workflow business processes on top of the Restlet framework. myERP, a SaaS vendor, are using Restlet framework for their open API; and to big companies, like LinkedIn, Google, HTC, Envidia, or IBM who, at some point, used the Restlet platform as a web API project; some company contributing back to the framework – like Ericson made a very large contribution to the framework on the OAuth 2.0 front. And, government agencies like NASA and universities and cancer research were using it a lot at one point in time. So, a very broad and diverse community and then we are seeing some interesting usage of APISpark, which is a new kind of platform, more accessible to non-Java engineers, non-REST experts. So, we are asking people who are coming from HR departments who have some Google spreadsheet and they want – they would quickly create a web API from their data. So, they start to use APISpark for these kinds of use cases. So it is great to broaden the type of developers or users of a platform in general.
It really is the fact that you do not have to program to build and to deploy your API. Everything can be done visually from a web browser, as long as you get your data either from APISpark - because we can host the data or we can also connect to an existing data source. So, as long as you have access to this data, you can define it. Exporting, deploying, managing the API can be done very easily visually. So, a non-technical user can do it. He wouldn’t be able to use Restlet framework or JAX-RS: you have to be a Java engineer to do that. So, definitely the barrier of usage is lower and the platform has been built to support multiple parties that are part of a web API project: from the developer, to the manager, to the operator of the API and the actual owner of the API, and the data. Because an API is a real project: you need to have a team, a budget, a business model behind that. So, with APISpark, we try to support all these needs and points of view on your web API project and, obviously, support your API consumers.
Charles: Great. That is a lovely place to end it. Jerome, thank you very much indeed.
You are welcome. Thanks a lot, Charles.