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.
A few weeks ago I had the privilege of attending and speaking at the API Strategy and Design Conference in Austin, TX. First and foremost, if you haven't been to Austin, and you get the chance to go - do. The key takeaway, Frank's - a hotdog joint where you can order ridiculous hotdogs and get cheesy fries with salsa (absolutely a delicious heart attack waiting to happen).
The other takeaways:
APIs are Critical to Success
Businesses everywhere are realizing just how important APIs are to their success. No longer can businesses afford to be silo'd, but even the most isolated companies find themselves now implementing SaaS services and having to extend their platform.
The real takeaway is, if you don't invest in your API, you can be sure your competitors will invest in theirs. And developers and consumers alike are shifting to a platform as a services (PaaS) mindset.
Models Are Key
During the hypermedia track, we took a look at the specifications out there (including Collection+JSON, HAL, Siren, CPHL, and others).
Wow, the 2 weeks since our last blog posts have been amazing, again. We've received an incredible amount of great feedback for the RAML 1.0 RC specification itself, and for the tooling (especially API Workbench), via email, and twitter, and the RAML.org forum, and github, even in person. Reading all these has been a real pleasure, and had demonstrated not only that things are on the right track with 1.0 and the tooling but also generally the value that a very broad community gets from RAML and its ecosystem. So where are things now -- how close are we to finalizing 1.0?
It's been a month since the 1.0 RC was published, and it's now looking like it'll take another couple of weeks or so to fully finalize it. We're making a lot of improvements in the wording and in the specificity, correcting some typos and examples, disambiguating in a few remaining places, and also tweaking some functionality based on this very constructive feedback. Here are highlights of those tweaks and improvements:
It’s been two weeks since the release of RAML 1.0 (RC), the new raml.org website, and the API Workbench; all been very well received in the community. A lot happened in this two weeks, so let me share some details on the release and quotes we had from the community on different channels.
It's a big day for RAML. We're excited to announce the publication of the RAML 1.0 (RC) spec, as well as the launch of a gorgeous new RAML.org site. In addition, our community is now launching a set of brand new development tools that support RAML 1.0 as well as 0.8. Here's what you need to know.
What's new with RAML 1.0?
RAML has always been about making it easy for developers to manage the whole API lifecycle from design to implementation to operation and sharing. It's a concise, intuitive language for specifying APIs that allows developers to only write what they need to define an API, drawing from and contributing to commonly-used patterns, such as the YAAS (SAP hybris) pattern library.
We’re about to finalize the next version of RAML. Last month we published the result of many months of community feedback, development modeling, and API analysis, in which we figured out how a rather small number of changes in RAML 1.0 (relative to its predecessor, RAML 0.8) could result in dramatic improvements to the modeling capabilities. The list resolves some gaps, enhances capabilities, and maintains the simplicity of RAML. This month, that list will turn into RAML 1.0.
Why so few changes?