RAML (software)

El lenguaje de modelado de API RESTful ( RAML ) es un lenguaje basado en YAML para describir API estáticas (pero no API REST). ^{[ 2 ]} Proporciona toda la información necesaria para describir API en el nivel 2 del Modelo de Madurez de Richardson . Aunque fue diseñado pensando en las API RESTful, RAML no es capaz de describir API que cumplan con todas las restricciones de REST (en particular, no puede describir una API que cumpla con HATEOAS ). Fomenta la reutilización, permite el descubrimiento y el intercambio de patrones, y busca la aparición de mejores prácticas basadas en el mérito. ^{[ 3 ]}

RAML se propuso por primera vez en 2013. La especificación inicial de RAML fue escrita por Uri Sarid, Emiliano Lesende, Santiago Vacas y Damian Martinez, y obtuvo el apoyo de líderes tecnológicos como MuleSoft, AngularJS, Intuit, Box, PayPal, Programmable Web y API Web Science, Kin Lane, SOA Software y Cisco. ^{[ 4 ]} El desarrollo está a cargo del Grupo de Trabajo de RAML. ^{[ 5 ]} Los firmantes actuales del grupo de trabajo incluyen líderes tecnológicos de MuleSoft (Uri Sarid, CTO), AngularJS (Misko Hevery, fundador del proyecto), Intuit (Ivan Lazarov, arquitecto jefe empresarial), Airware (Peter Rexer, director de producto - plataforma para desarrolladores), Programmable Web and API Science (John Musser, fundador), SOA Software (Tony Gullotta, director de desarrollo), Cisco (Jaideep Subedar, gerente sénior de gestión de productos - grupo de soluciones de integración de aplicaciones), VMware (Kevin Duffey, ingeniero sénior de MTS), Akamai Technologies (Rob Daigneau, director de arquitectura de la plataforma OPEN API de Akamai) y Restlet (Jerome Louvel, CTO y fundador). RAML es una marca registrada de MuleSoft. ^{[ 6 ]}

Muy pocas API existentes cumplen con los criterios precisos para ser clasificadas como API RESTful. Por consiguiente, al igual que la mayoría de las iniciativas de API en la década de 2010, RAML se centró inicialmente en los aspectos básicos de las API, incluyendo recursos, métodos, parámetros y cuerpos de respuesta que no necesariamente son hipermedia. Existen planes para avanzar hacia API más estrictamente RESTful a medida que la evolución de la tecnología y el mercado lo permitan.

Hay varias razones por las que RAML ha dejado de ser un lenguaje propietario de un proveedor y ha demostrado ser interesante para la comunidad de API en general: ^{[ 7 ]}

• RAML se ha publicado como código abierto junto con herramientas y analizadores sintácticos para lenguajes comunes. El desarrollo de RAML será supervisado por un comité directivo de profesionales de API y UX, y existe un ecosistema emergente de herramientas de terceros que se están desarrollando en torno a RAML ^{[ 8 ].}
• MuleSoft comenzó originalmente usando Swagger (ahora especificación OpenAPI ), pero decidió que era más adecuado para documentar una API existente, no para diseñar una API desde cero. RAML surgió de la necesidad de admitir el diseño inicial de API en un lenguaje conciso y centrado en el ser humano ^{[ 9 ].}
• Las descripciones de las API suelen ser extensas y repetitivas, lo que puede dificultar su comprensión y uso, y ralentizar su adopción. RAML ha introducido características de lenguaje que admiten archivos estructurados y herencia, abordando así problemas transversales ^{[ 10 ].}

Una nueva organización, patrocinada por la Linux Foundation , llamada Open API Initiative, se creó en 2015 para estandarizar la descripción de las API HTTP. Varias empresas, entre ellas SmartBear , Google , IBM y Microsoft, fueron miembros fundadores. ^{[ 11 ] [ 12 ]} SmartBear donó la especificación Swagger al nuevo grupo. RAML y API Blueprint también están siendo consideradas por el grupo. ^{[ 13 ] [ 14 ]}

Este es un ejemplo de archivo RAML. Al igual que en YAML, la indentación muestra el anidamiento.

#%RAML 0.8Título : API de música del mundobaseUri : http://ejemplo.api.com/{versión}versión : v1rasgos :- paginado :parámetros de consulta :páginas :Descripción : El número de páginas a devolvertipo : número- asegurado : !include http://raml-example.com/secured.yml/canciones :es : [ paginado , seguro ]conseguir :parámetros de consulta :género :Descripción : Filtra las canciones por género.correo :/{songId} :conseguir :respuestas :200 :cuerpo :aplicación/json :esquema : |{ "$schema": "http://json-schema.org/schema","tipo": "objeto","descripción": "Una canción canónica","propiedades": {"título": { "tipo": "cadena" },"artista": { "tipo": "cadena" }},"obligatorio": [ "título", "artista" ]}aplicación/xml :borrar :Descripción : |Este método *eliminará* una **canción individual**.

Algunos aspectos destacados:

• líneas 7, 12: define rasgos, invocados en múltiples lugares
• línea 12: un archivo de inclusión
• líneas 13, 14: define un tipo de datos "recurso" "/songs"; utiliza rasgos definidos previamente
• líneas 15, 19, 37: define métodos HTTP
• líneas 25, 36: Tipos MIME .

• Apigee
• MuleSoft
• Puerta de enlace de API de AWS (a través del importador de puerta de enlace de API de AWS )
• Akana
• Restlet

Además, puede convertir su especificación RAML a OpenAPI o API Blueprint utilizando APIMATIC , lo que le permitirá utilizar otras pasarelas API.

• Especificación OpenAPI
• MuleSoft
• Transferencia de estado representacional
• YAML
• API de Java para servicios web RESTful
• SoapUI
• Prueba SOA
• Reducción

• Especificación OpenAPI
• Plano de API
• WADL

• Sitio web oficial de RAML
• Repositorios RAML en Github
• Un plugin RAML/APIHub para SoapUI
• RAML Open Specification and Tools Released to Help in API Design Archived 2014-03-21 at the Wayback Machine
• Ross Mason, fundador de MuleSoft, habla sobre cómo evitar el apocalipsis de las API.
• MuleSoft hace que la gestión de API sea más accesible.
• Plugin Maven para Spring WebService a RAML