InfoQ had the opportunity to speak with Uri Sarid, the CTO of MuleSoft at their CONNECT 2016 annual conference in San Francisco. Sarid is the creator of RAML, which just released its long awaited version 1.0 in GA, so it was a good opportunity to follow-up from last year’s interview and also to get a broader view on MuleSoft’s solutions for API teams and his vision for APIs.
InfoQ: What is your role at MuleSoft and where do APIs fit into your work?
Uri Sarid: My role is CTO and that means that I'm responsible for our platform vision and direction as well as its architecture. APIs are front and center in everything we do. They are central to our approach, which we call API-led connectivity, and they allow an ecosystem of services which we call the API economy, to exist.
InfoQ: What is the vision of MuleSoft regarding APIs? Is it mostly about integration needs?
Sarid: The vision for MuleSoft is to enable our customer and general industry to create application networks, and in doing so to connect the world’s apps data & devices. An application network is a network of applications, data and devices connected with APIs to make them pluggable and to create reusable services.
InfoQ: Which products does MuleSoft offer that help developers and architects in their API projects?
Sarid:We offer a platform rather than a suite of products to cover the full API life cycle. If you are creating APIs, that means everything from the very first ideation and trial of what it is that you are creating, through to the productization of that API interface, to the implementation, the deployment, the operations and the management, getting insights into how it is doing and through to user engagement and retirement.
InfoQ: What level of API adoption and maturity do you see among your large enterprises and SMBs customers?
Sarid: Firstly, APIs in term of recognition, interest, and investment have crossed the chasm. It’s hard for me to think of any business of any significant size that has not understood and that isn’t actively integrating API in their core strategy and business.
Having said that, the market is far from mature in terms of what that entails and how to do it well.
InfoQ: Do you think integration PaaS (iPaaS) and API Management will eventually merge, or stay mostly separate?
Sarid: In our minds, they have merged already. Our platform is a comprehensive solution for iPaaS and API Management and we’re seeing that our customers expect this type of complete solution.
Customers see value in API management and in distributed ESB. There are places where you need an iPaaS and customers increasingly don't see them as different solutions.
A perfect example of this is that customers want to make sure that the integration they've created with an ESB has well-managed APIs on top of it, so they can easily access data as needed.
InfoQ: You just announced the GA of RAML 1.0 after a long period of maturation. Can you describe what's new and why it took so long to be delivered?
Sarid: The major change is the ability to model data easily in a format-independent and reusable way, and more generally to easily reuse conventions, patterns, and anything else that you or someone else already developed.
With RAML 1.0, API developers can create and reuse design libraries across network components, improving design consistency and speeding API delivery. Additionally, annotations provide powerful and controlled extensibility, while YAML-based and named examples enhance human readability, easing collaboration and developer onboarding.
InfoQ: What is the level of adoption of RAML compared to alternatives and its main differentiators?
Sarid: What we are really starting to see, and where we want things to go, is people seeing the importance of the API as a contract. This mindset encourages developers to choose a way to describe that contract as it makes sense to their organization. Then they'll say, what are the best practices to doing that.
When comparing Swagger and RAML people are recognizing that RAML adds some things on top of the Open API Specification (OAS, fka Swagger specification). It offers a lot of features for reuse.
The RAML users we talk to say that RAML is their choice for the source code of the description of the API and they are looking to the community to provide interop tools so they can make full use of the API ecosystem, now that the specifications are compatible with each other functionally.
InfoQ: When do you plan to release the tooling that will fully support RAML 1.0?
Sarid: We already released early access to RAML 1.0 tooling, but there are still a few gaps. All the parsers that we released have closed this gap and we are in the final stage, intaking those parsers and releasing them in the fully functional platform.
Because the parser and the API Workbench are open sourced at this point, this allows the community to finalize their support for 1.0 in parallel.
There are hundreds of community projects out there. It should happen in the next few weeks or months for them. To support that, there is a lot of documentation and even a Test Compatibility Kit (TCK) to make sure that you are fully compatible with the spec.
We are also working on modularizing API Workbench into individual tools that can be used one by one in other projects to accelerate.
InfoQ: How is the RAML governance evolving? Do you have plans to move it to a standardization body, like Swagger did by launching the Open API Initiative?
Sarid: The governance has been more community-driven and less formal so far. We are open to doing it in one way or the other. We maintain an active interest in working with the Open API Initiative so there is only one thing to govern, but that's an ongoing conversation.
InfoQ: As APIs are technical by nature but take an increasingly important place in software projects, how do you think the gap between functional and technical people can be bridged?
Sarid: I think it’s driven not so much by making the technical part more accessible, but how we make the approach of API more accessible to business. Let's say some department of a company needs to have a certain set of data sources; why not make those into reusable assets, by building an application network? It's clear what the business is going to ask. What you will be showing them is an API, that will drive the access to that data. This is more valuable than just focusing on making API Console more accessible.
InfoQ: In your experience, how quickly are API developers transitioning from code-driven to contract-driven API development workflows? Is the API tooling in general ready to support this more industrial phase?
Sarid: The movement is definitely happening, though it’s hard to put numbers on it. We are certainly seeing a lot more advocacy for it, while three years ago when we launched RAML we felt more like a lone voice in the desert. And as tools for making use of API contracts mature, developers see increasing utility and time savings in design-first, so it’s definitely no longer just a best practice- it’s a very practical one too.
InfoQ: There seems to be a continuous resurgence of RPC on the web, such as gRPC from Google. How do you analyze this phenomenon?
Sarid: I think this is the pendulum that we see with APIs over and over again, between strong typing and spec and loose typing and lack of structure. Another is very structured semantics for the API (CRUD) and very unstructured (invoked functions on remote systems), text based (JSON, headers) versus binaries (gRPC or ProtoBuf) and we will continue to see the world swing between those pendulums.
I think our role in the API ecosystem is to identify when you should use one versus the other and provide good support for it. You need to be able to take the old and new systems and to guide new APIs with optimal choices they should make.
InfoQ: What is the state of hypermedia APIs from your point of view? Is it an alternative to regular APIs or complementary like Microsoft Graph API is hinting at?
Sarid: I don't think it is an alternative; it’s more of an evolution. Hypermedia is about embedding more than data in APIs, control other metadata.
So I think we are all still figuring out how and when to get the best value out of this approach. I'm very optimistic that we will figure this out in the coming year based on work that has already been done and that will find its sweet spots.
InfoQ: In a previous interview, Daniel Jacobson questioned the value of formal API description languages for ephemeral APIs. Do you agree with him, and do you see other cases where formally specifying APIs, using RAML for example, is not desirable?
Sarid: It's impossible to say that there is no value.
Many APIs will evolve every day, like a client application API. You can use code generation, auto testing to see if you broke your release if that's the way you run your CI/CD, and not invest time into designing your API at all, just have the API spec emerge, and evolve continuously as it adds value “from the side”.
On the other hand, sometimes to go fast you do really need to move in parallel, and an API spec allows that to happen. The API may not need to actually evolve quite as rapidly as the UI on top of it, in which case having them evolve in parallel and at slightly different speeds, with the API spec defining the boundary and minimizing the friction, can be very advantageous.
InfoQ: What are the pain points and best practices that you found within MuleSoft around your APIs? Are there any specific tooling or workflow that you are using?
Sarid: We are using our own platform obviously. We have the classic problem of every company that believes what it is saying to its customer. That's the bootstrapping problem meaning, I advocate something, I build tools for this and need to use those tools to build them, but obviously I'm still developing them. As a result, the problem is that we find a constant need for improving and broadening our own platform to serve our needs. Those needs are building our own platform to benefit us and our customers. So I guess that’s a good problem to have.
I think we haven't necessarily solved yet how to rapidly collaborate either inside a team or across multiple teams even though we have APIs for our services and we do API first. We found our own API infrastructure isn't efficient enough so we've prioritized that in our roadmap because it will help not only our customers but also our own ability to deliver our products.
InfoQ: At CONNECT 2016, you did a presentation with Netflix on Application networks and microservices. What is the role of API and DevOps in this emerging landscape?
Sarid: We see APIs and operationalization as the two pillars of microservices. Ops in the form of DevOps practices, container orientation, and highly automated orchestration has gotten a lot of attention, for example through Docker and Kubernetes, but now the market is realizing that APIs play just as an important role in effective microservices, and that was certainly demonstrated in that talk.
APIs define the boundaries of your microservices; just like the boundaries of a living cell are critical to the well being of the cell, regulating what’s in and what’s out, APIs play a similar role in regulating the ecosystem in which the microservice lives.
Then, when you have a strong API mindset and ops mindset, you can engage in the best practices that we see at Netflix, such as using Chaos Monkey, Hystrix and so on.
InfoQ: There was a recent legal decision around Java APIs between Oracle and Google. What happened and how is it impacting web API projects?
Sarid: It's a fascinating time we are living in. In the USA, APIs are copyrightable, but not in Europe. A court has now ruled that the way Google used the Java APIs is a “fair use” and therefore not subject to restriction or payment. We are still figuring what that means to the web APIs that are so critical to power our economy.
There are two reasons to be optimistic. First off, in the latest ruling a jury concluded that Google had made “fair use” of Oracle Java APIs, and specifically accepted Google’s argument that it was fair use because developers were familiar with those APIs- not because it encouraged interoperability. In future cases where the purpose actually is interoperability, I’d expect even more that courts will accept fair use arguments, further reducing the threat of copyright litigation.
The second reason looks back at what copyright really protects, which is the expression of an original expression of an idea and not the idea itself, nor purely utilitarian expressions of it. For example, if there is substantially only one way or expressions something, that’s not copyrightable, and if the expression itself is completely utilitarian and non-creative, then that too isn’t subject to copyright.
Now, the API economy is driving APIs to be more standardized, more plain and predictable using common words and structures, more utilitarian and obvious. As APIs become more and more utilitarian in this way, and maybe much less creative, we hope that the courts will rule that such APIs are in fact not even copyrightable.
We wrote a detailed blog post on this important legal decision if you want additional details.
InfoQ: What is your vision of the future of web APIs? What’s the next big thing that needs to happen to accelerate usage of APIs across all sizes of enterprises?
Sarid: Now that APIs have reached a certain level of maturity, the vision for the future is how organizations will drive value and reuse out of them. The value of web APIs comes into being when you use them to create a network of applications.
By using APIs to create a seamless collection of applications that can be assembled and reassembled, businesses can derive greater value from them.
APIs get their value by being incorporated into business process. For example, if web APIs expose more metadata information about themselves, it makes discovery easier and incorporating them into business processes easier. This allows businesses to see how well a web service is operating.
I think we do need to lean more heavily into the discovery and the consumption experience; it has to be improved. For example, we already help with that in RAML with its format independent data types so that developers aren't encumbered with the complexity of format-specific schema such as JSON Schema and XML Schema (especially citizen developers).
We also invested into examples in the RAML spec, and into API Notebook, so developers can easily see how they are supposed to consume those APIs, what the use cases are and so on. And you will see us and other players getting the discovery and consumption experience to be much more powerful and easier, and the options for creating APIs as well.