A Standard for API modeling, documentation and exploration

get it
There are no images or videos added to the gallery.
Add to gallery



MakersThere are no makers yet
You need to become a Contributor to join the discussion - Find out how.
Romain Dardour
Romain DardourHunter@rdardour · Co-founder, hull.io
Plenty of those come out often, this one handles the right concerns for both API builders and consumers
Gregory Koberger
Gregory Koberger@gkoberger · Founder, ReadMe.io 📘🦉
If anyone is using RAML for their API and is looking for an easy way to turn it into something consumer-facing, I'm looking for beta testers: greg@readme.io (please don't post it to PH yet!)
Krish Dholakiya
Krish Dholakiya@krrishd · itskrish.co
Any particular reason YAML was chosen over JSON for the spec (I wouldn't know why one is better than the other in a particular context)?
Dillon Compton
Dillon Compton@comptly · Sales/Growth
@krrishd Hi Krish, I was the original PM on many of MuleSoft's contributions to RAML. The working group went with YAML over JSON for a few reasons, but most notably is that it is much more human-readable than JSON, especially for less-technical folks. They were trying to create something that stakeholders (like PMs) could easily consume and collaborate on with developers. In addition, the group felt that YAML's whitespace-as-a-semantic requirement would create API docs that were structured in a very similar way to your APIs -- you can literally see resource relationships, something that is not very enforceable in JSON. There were a number of other reasons that arose in early discussions, but human readability and inherent structure were the two biggest ones!