Blog : Tooling
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.
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.
Currently we are compiling a series of guest posts where we ask happy RAML user to tell their stories about how they are using RAML, or their tools they developed and contributed to the RAML community. In our very first post in this series, I am happy to have ePages to talk about their experience and the tool they developed. If you want to talk about your story or tool, why not sending us an email to email@example.com.
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.