RAML

A Standard for API modeling, documentation and exploration

Featured Embed
Reviews
Discussion
MakersThere are no makers yet
You need to become a Contributor to join the discussion.
Romain Dardour
Romain DardourHunterHiring@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!