RAML (software)

RAML

Filename extension	.raml
Internet media type	application/raml+yaml
Developed by	RAML Workgroup
Latest release	0.8 (October 2, 2013 (2013-10-02))
Extended from	YAML
Standard	raml.org/raml-10-spec
Website	raml.org

RESTful API Modeling Language (RAML) is a YAML-based language for describing RESTful APIs. 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.

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. 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

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:

• 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
• Mulesoft originally started with Swagger (now OpenAPI Specification) but decided it 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
• API descriptions are often verbose and repetitive which can hinder their structure, understanding and consumption. RAML has introduced language features that support structured files and inheritance that address cross-cutting concerns

A new organization, under the sponsorship of the Linux Foundation, called the Open API Initiative was set up in 2015 to standardize the description of RESTful APIs. A variety of companies, including Swagger, Google, IBM and Microsoft are founding members. Swagger donated the Swagger specification to the new group. RAML and API Blueprint are also under consideration by the group.

Example

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

  #%RAML 0.8

  title: World Music API
  baseUri: http://example.api.com/{version}
  version: v1

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

  traits:
    - paged:
        queryParameters:
          pages:
            description: The number of pages to return
            type: number

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

    - 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.

  /songs
    is: [ paged, secured ]
    get:
      queryParameters:
        genre:
          description: filter the songs by genre
    post:
    /{songId}:
      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.

        responses:
          200:
            body:
              application/json:
                schema: |
                  { "$schema": "http://json-schema.org/schema",
                    "type": "object",
                    "description": "A canonical song",
                    "properties": {
                      "title":  { "type": "string" },
                      "artist": { "type": "string" }
                    },
                    "required": [ "title", "artist" ]
                  }
              application/xml:
      delete:

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

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

See also

• OpenAPI Specification
• Overview of RESTful API Description Languages including OpenAPI Specification, RAML, WADL, WSDL, and others
• MuleSoft Inc. & CR7
• Representational State Transfer
• YAML
• Java API for RESTful Web Services
• SoapUI
• SOAtest
• Markdown

Alternative RESTful Modeling Languages

• OpenAPI Specification
• API Blueprint
• WADL

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