RAML (software)

RESTful API Modeling Language (RAML) is a YAML-based language for describing RESTful APIs.^[2] It provides all the information necessary to describe RESTful or practically-RESTful APIs. Although designed with RESTful APIs in mind, RAML is capable of describing APIs that do not obey all constraints of REST (hence the description "practically-RESTful"). It encourages reuse, enables discovery and pattern-sharing, and aims for merit-based emergence of best practices.^[3]

History

RAML was first proposed in 2013. The initial RAML specification was authored by Uri Sarid, Emiliano Lesende, Santiago Vacas, and Damian Martinez. Development is managed by the RAML Workgroup.^[4] The current workgroup signatories include technology leaders from MuleSoft Inc. (Uri Sarid), AngularJS (Misko Hevery, Project Founder), Intuit Inc. (Ivan Lazarov, Chief Enterprise Architect), Box Inc. (Peter Rexer, Senior Platform Product Manager), PayPal Inc. (Jason Harmon, Head of API Design), Programmable Web & API Web Science (John Musser, Founder), Kin Lane (Presidential Innovation Fellow, Department of Veteran Affairs), SOA Software (Tony Gullotta, Director of Technology), and Cisco (Samar Choudary, Lead Architect, Application Integration Service Group). RAML is a trademark of CR7^[5]

The current version of RAML is not restricted to strictly RESTful APIs because it would have not applied to almost any existing APIs and not been feasible for most API initiatives to adopt today, so RAML is starting with the basics of RESTful APIs—resources, methods, parameters, and bodies that need not be hypermedia with plans to evolve from there

While RAML could end up being just a proprietary vendor language there are a number of reasons why this language is interesting to the broader API community:^[6]

• RAML has been open-sourced along with tools and parsers for common languages. The development of RAML will be overseen by a steering committee of API and UX practitioners and there is an emerging ecosystem of third-party tools being developed around RAML^[7]
• Mulesoft originally started with Swagger but realised that standard was best suited to documenting an existing API, not for designing an API from scratch. RAML evolved out of the need to support up-front API design in a succinct, human-centric language^[8]
• API descriptions are often verbose and repetitive which can hinder their structure, understanding and consumption. RAML has introduced language features that support structured files, inheritance and that address cross-cutting concerns^[9]

YAML was chosen as the baseline syntax for RAML because:

• YAML is a very well known superset of JSON
• YAML is optimized for human readability
• YAML reveals hierarchies clearly and cleanly
• YAML minimizes the need for curly brackets, quotes, and other "cruft"
• YAML allows for internal references to minimize repetition and maximize succinctness
• YAML has a very broad base of well known and understood tools

Example

Start by defining which version of RAML you are using, and then document basic characteristics of your API — the title, version, and baseURI:

1   #%RAML 0.8
2 
3   title: World Music API
4   baseUri: http://example.api.com/{version}
5   version: v1

RAML allows you to define patterns using traits, resourceTypes, and securitySchemes, and then use them within an API to minimize repetition:

 6   traits:
 7     - paged:
 8         queryParameters:
 9           pages:
10             description: The number of pages to return
11             type: number

Externalize those patterns, store them on the web, and import them with an !include:

12     - secured: !include http://raml-example.com/secured.yml

Define resources and methods, then add as much detail as you want. Apply traits and other patterns, or add parameters and other details specific to each call.

13   /songs
14     is: [ paged, secured ]
15     get:
16       queryParameters:
17         genre:
18           description: filter the songs by genre
19     post:
20     /{songId}:
21       get:

Describe expected responses for multiple mime-types and specify schemas and examples for each one. Schemas and examples can be defined in-line, or externalized with !include.

22         responses:
23           200:
24             body:
25               application/json:
26                 schema: |
27                   { "$schema": "http://json-schema.org/schema",
28                     "type": "object",
29                     "description": "A canonical song",
30                     "properties": {
31                       "title":  { "type": "string" },
32                       "artist": { "type": "string" }
33                     },
34                     "required": [ "title", "artist" ]
35                   }
36               application/xml:
37       delete:

Write human-readable, markdown-formatted descriptions throughout the RAML spec, or include entire markdown documentation sections at the root.

38         description: |
39           This method will *delete* an **individual song**

See also

• MuleSoft Inc. & CR7
• Representational State Transfer
• YAML
• Java API for RESTful Web Services
• SoapUI
• SOAtest
• Markdown

Alternative RESTful Modeling Languages

• Swagger
• API Blueprint

Notes

References

External links

• RAML official website
• RAML RESTful API Creation (YouTube Video) Example
• RAML Repositories on Github
• A RAML/APIHub Plugin for SoapUI
• RAML Open Specification and Tools Released to Aid in API Design
• MuleSoft founder Ross Mason on avoiding API armageddon
• MuleSoft Makes API Management More Accessible