Blog : Updates
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.
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.
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 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?
Hi @all, we are proud to announce that we were able to add a couple of new projects to our list. Check them out on: raml.org/projects.html Here an overview:
Today, InfoQ released an interview with Uri Sarid, the founder of the RAML project. Uri is talking about the current status of the project, the new sponsorship of the Swagger project from SmartBear, and also scratches a little bit on RAML 1.0. Enjoy the full interview here.
MuleSoft has released a couple of new key features around their Anypoint Platform offering in February 2015. One in particular is interesting for the RAML community. The RAML console got a refreshed UI as well as new features which I will briefly explain here.Before we start, for everyone who does not know the console, let’s have a quick overview of it. The RAML console is an open source application and gives you a graphical insight of your API specification. It lists all resources and by clicking on the attached HTTP verbs on a specific resource you will be able to deep dive into the resource details. The detail page features a general description, descriptions of every possible HTTP status, examples and schemas on the response’s and/or request’s body, and other aspects you defined in your RAML specification.So what really is new? As I said - the UI was completely refreshed and got a more modern look & feel.