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.
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: