design - standard - ¿Hay alguna práctica de diseño estándar para arquitecturas RESTful?
standard rest (6)
Una de las desventajas de ser autodidacta es que siempre estás reinventando la rueda.
Trabajo cada vez más en arquitecturas RESTful y, como resultado, necesito definir recursos y cómo uno puede interactuar con ellos.
¿Existen métodos o plantillas de diseño estándar (y efectivos) que ayuden a enumerar los diversos verbos HTTP y las posibles respuestas de los recursos para ayudar a garantizar que todas las permutaciones estén cubiertas?
Incluso algo tan básico como:
+----------------+---------------------------------------------+
| Resource Name: | |
+----------------+---------------------------------------------+
| HTTP METHODS |
+------------+-------------------------------------------------+
| Method | Supported |
+------------+-------------------------------------------------+
| GET | X |
| PUT | X |
| POST | |
| DELETE | |
+------------+-------------------------------------------------+
| RESPONSES |
+--------------------------------------------------------------+
| GET |
+--------------------------------------------------------------+
| Details of valid and necessary parameters for GETs and the |
| possible responses... |
| ... |
+--------------------------------------------------------------+
Claro ... podría hacer mi propia versión, pero me pregunto si hay metodologías ampliamente reconocidas que pueda adoptar.
El método más ampliamente aceptado y entendido es hacer que sus mensajes RESTful sean autodescriptivos:
GET /foo HTTP/1.1
HTTP/1.1 200 OK
Allow: GET, PUT
...
{"description": "A foo. PUT a new representation to overwrite this one.", ...}
/foo es el "Nombre del recurso", el encabezado "Permitir" es la lista de "MÉTODOS HTTP", y el cuerpo de respuesta delinea la información "RESPUESTAS", ya sea en prosa o como un conjunto de controles (como un formulario HTML).
Para asegurarse de que todas las permutaciones estén cubiertas, escriba pruebas.
Es posible que desee echarle un vistazo al Lenguaje de descripción de la aplicación web . Algunos marcos REST incluso pueden generar la descripción para usted. Me gusta mucho Jersey Apache (si puede aceptar Java para la implementación).
No hay métodos estándar para diseñar API REST, hasta donde yo sé. Y las personas a menudo pasan demasiado tiempo discutiendo si deberían usar PUT o POST para un método en particular. Creo que lo más importante es mantenerlo simple, ser coherente con el uso de verbos y formatos, y documentarlo extremadamente bien.
No creo que deba tratar de cubrir todas las permutaciones de verbos y recursos HTTP, porque lo más probable es que no lo necesite .
Si está buscando una plantilla, eche un vistazo a las pautas de REST API de Atlassian . En mi experiencia, una wiki funciona mucho mejor que cualquier tipo de herramienta que autogenera documentación desde el código.
No existe una forma estándar de describir el diseño de una Aplicación / API RESTful porque REST es un principio de arquitectura + método y no un marco bien definido o un patrón de diseño.
Puede usar cualquier herramienta para describir sus recursos y sus interacciones (desde una hoja de cálculo simple hasta un diagrama UML, si lo desea). Todo funcionará tan lejos como puedas leer 3 elementos principales en el documento resultante:
- Los recursos que su aplicación proporcionará
- Los métodos que aceptarán cada recurso
- Los enlaces entre cada recurso
A partir de este punto, podrá crear el esquema de URL interno de su aplicación, crear la URL pública, etc.
RestMS.org contiene un estándar para diseñar API Restful.
No debe tratarse como un evangelio, pero aprenderá mucho leyendo la definición de RestTL (capa de transporte relajante) de una sola página.
Desde que publiqué esto, recientemente descubrí varios diseñadores de API. Uno de estos ( Mulesoft''s Anypoint Platform ) usa un lenguaje llamado RAML (RESTful API Modeling Language).