Today, MuleSoft joined the OAI and open sourced a new API tool called the API Modeling Framework (AMF).
We are excited to make AMF available to the community, bringing together the RAML and OpenAPI ecosystems. AMF provides an approach to developing API that provides for parsing, interacting with, and generating API descriptions in any API description language.
Currently, there are several API description languages, like RAML and OpenAPI Specification (OAS). Without a way to provide tooling that can easily understand any API description language or a mechanism to go back and forth between languages easily, developers had to make a choice. AMF changes that.
We built a way to parse and generate any API specification (e.g. RAML or OAS) in a few steps. AMF makes RAML and OAS interoperable.
We are happy to welcome our new member for the RAML Workgroup - Jerome Louvel.
Jerome is the Founder, CTO and VP of Products of Restlet and an expert in REST APIs. He was trained as an engineer in computer science and management, graduate of Polytech'Montpellier.
After working several years in IT consulting and for a software startup in the US, he started the open source Restlet Framework project back in 2004, as the first REST API framework. More recently, he has created Restlet Platform, a API-first PaaS for DevOps teams that includes Restlet Studio module, the first cross-language visual API designer and Restlet Cloud module for data-driven APIs creation and deployment. He also managed the acquisition of an API testing tool available as a Chrome Extension and its integration within Restlet Platform as the Restlet Client module.
Jerome is also an editor for InfoQ on web APIs and was part of the Java Community Process experts group who defined the JAX-RS 1.0 API. He co-authored the 'Restlet in Action' book (Manning) and contributed to the 'RESTful Web Services' book (O'Reilly) as well.
Please join me in welcoming Jerome!
The RAML Workgroup
What exactly is the RAML TCK?
The RAML TCK has been developed to help people that create a parser for RAML in their favorite language to validate that their implementation complies with the RAML specification.
The RAML TCK provides a set of RAML definitions in JSON format that are either valid or invalid. You can load these files and compare them against the output of your parser to see if both matches.
The RAML TCK is already been used successfully inside the JS and Java parser to identify issues early on during the most critical period in the past. During that time, the TCK repository grew with each issue found or raised by the community, and after some cleanup we are able to release it now.
Communities are the backbone of every open-source technology. In fact, the RAML community made RAML what it is today. The time people spend to help on the specification and building tools cannot be valued, especially that most of you do that on their free will.
For all of you who helped so far evangelizing RAML by writing blogs, doing talks, promoting it in your company, or by developing tools; and for all of you who want to continue, or plan, to accompany us on our journey we've built a program designed to get you closer and more involved with the RAML community than ever. With the RAML MVP program, you can share best practices, network with RAML user around the world, or just have fun by taking on different challenges. We’re thankful to have such an awesome community and created this as a way to not only showcase all the hard work that you do but to help you grow and develop your RAML skills.
It's been a while since the release of RAML 1.0, and we would like to do a reflection on where we are with regards to the specification, tools, and community.
Since May, we got an immense number of positive feedback around the new features we introduced with RAML data types being the favorite change by far. Many people also helped the RAML Workgroup to identify hidden mistakes inside the specification and other missing clarification in certain areas so that we were able to release our first patch release in July.
We will continue to provide patch releases that increase the quality of the specification. The next upcoming release we currently plan between the end of October and mid-November. See more information here.
We are so happy to welcome our new member for the RAML Workgroup - Rob Daigneau.
Rob Daigneau is a technology thought-leader, experienced executive, evangelist, consultant, and mentor with a passion for web service and API Design, REST, SOA, cloud computing, and distributed systems engineering.
He has over twenty years' experience leading the design and implementation of software products for a variety of industries, from financial services, to manufacturing, to retail and travel. Rob has served in such prominent positions as Director of Architecture for Monster.com, and Manager of Application Development at Fidelity Investments. He currently serves as the Principal Architect for Akamai's OPEN API platform.
Since RAML was introduced to the world in its infant version 0.8 state, it has gained huge interest in the community. There has been adoption by large companies like Oracle and Amazon, and support for it now exists in popular tools like SoapUI, PostMan, Restlet, and RAMLfications.
Today we are excited to announce the release of RAML 1.0 GA (release notes).
People that carefully watch our specification repository might have already realized that we were able to close all issues and merge the RAML 1.0 RC2 branch into its predecessor. Therefore, we are very happy to finally announce the official release of our next release candidate RAML 1.0 RC2.
As our journey to finalize RAML 1.0 continues, let us do a short stop talking about our the next release candidate RC2. When we released the very first release candidate (RC1) for RAML 1.0 back in November, who would have thought that we get the tremendous amount of feedback in the form of excellent reviews for the newly added features, but also in a fair amount of constructive feedback. For us, that was already a huge success and has shown us that we are on the right track. Now that we collected all the feedback for RC1, we need to do another analysis on all the open issues around that, decide what to do with them in RC2, before we start working to incorporate these changes.
First of all, as it’s been a while, but we should not forget it is a new year, so The RAML Workgroup wishes everyone a Happy New Year 2016.
Before we start with the current status of RAML 1.0, let me quickly say; wow, last year (2015) was fantastic for everyone who shares our passion around APIs and especially RAML. With Swagger evolving into the Open API Initiative, Apiary announcing their plans for API Blueprint, and the RAML Workgroup releasing their first release candidate for RAML 1.0 it was a year of significant announcements. We should all have realized by now; designing APIs is critical and should be the forefront of every API strategy. It will not only significantly help to improve the experience developers will have using APIs, but also the overall experience someone has using your APIs.