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