MuleSoft recently released a significant upgrade to their Anypoint platform for APIs which brings together API design, collaboration and API management features. InfoQ interviewed MuleSoft CTO, Uri Sarid to find out more about the platform.
US: The Anypoint API Portal is where you can design APIs in collaboration with your stakeholders and future app developers, mock them, document them, explore them before or after implementation with the console and the notebook and fully engage with your developer community. It's tightly integrated with the Anypoint API Manager, which gives you complete control over who can access your APIs, place limits on their usage, and measure and analyze how they're being used.
US: It's like any other product design, where careful craftsmanship and attention to the user experience — in this case, the developer users — yields disproportionately high benefits once the product is launched — in this case, the API being published. So you roughly sketch out the API appropriate for the domain and the primary use cases using RAML (the RESTful API Modeling Language), and quickly put it in the hands of some test users. Even in this rough, early phase, there's a live console for the API, and a mocked "implementation" of the service the users can prototype with (e.g. with prototype mobile apps), as well as a live scripting notebook that lets them quickly work out usage scenarios and share their findings. The design is important because the ecosystem that develops around a successful API carries its own momentum, which resists breaking changes to the API. With the API design iterated on until it's accepted by stakeholders, it's time to implement — with confidence now that a faithful implementation will yield delighted developers and the desired benefits. In many cases, the implementation of the API is an exercise in connecting to and from a myriad of existing on-premise and in-cloud systems; Mule Studio and its APIkit components make quick work of turning a RAML spec into a set of Mule integration flows that realize the spec, scalable and maintainably. The resulting Mule application can be deployed in CloudHub or on premise (or a private cloud), while the API it exposes is automatically bound to the Anypoint API Manager, where policies can be applied to it, and to the Anypoint API Portal, where it can be discovered and consumed by app developers.
US: Simply put, we realized ourselves what numerous others in the API space have realized: that Swagger and similar formats may be suitable as the *output* format of an API, something that expresses it after it exists, but they're not good for designing APIs. Nobody starts by writing down Swagger; they generate it from code, so the API is really designed via its implementation, which is a bit upside down. Moreover, it's quite a verbose description, which can easily lead to losing the forest in the trees: you get reams and reams of description, so you cannot see, and certainly cannot build in, a few clean patterns that can explicitly be reused throughout the API. With RAML, we aimed for a way of designing and expressing RESTful APIs that were as clean, expressive and efficient as REST itself. So far, so good.
US: The service registry continues to be a great place to, well, keep a registry of all your services, whether REST or SOAP or even things that many wouldn't even call APIs such as FTP locations. But we're adding many API-specific features to it, such as new policies, integration with the Anypoint API Portal and more integration with existing customer systems.
US: You can use Anypoint API Manager to control APIs that aren't implemented with Mule by proxying them through the API gateway. From a management perspective, or even a portal perspective, all the capabilities are available for these APIs as they would be if the implementation itself was in Mule.
US: Though this certainly feels like the golden age of APIs, there's tremendous room for growth too: many enterprises still have not rolled out broad API initiatives. API design is just now being recognized as a critical discipline, best practices are few and far between, and there's very little consistency across APIs, even within the same organization. There's a huge gap between the API have's and have-not's. And that's felt directly by API consumers, who more often than not struggle with APIs that seem like an afterthought — because they were.
