Cómo diseñar mejor las API RESTful
Una buena API RESTful debe tener las siguientes características:
Esta API debe ser compatible con el navegador y poder integrarse bien en la Web, en lugar de ser incompatible con la Web.
1. El navegador es el cliente REST más común y versátil. Una buena API RESTful debería poder completar todas las pruebas utilizando el navegador + HTML (no se requiere lenguaje de programación). Una API de este tipo también se puede probar fácilmente utilizando varias herramientas automatizadas de pruebas funcionales y de rendimiento web. Las aplicaciones web front-end (aplicaciones RIA basadas en navegador, aplicaciones móviles, etc.) también pueden combinar fácilmente las funciones de múltiples API RESTful para crear aplicaciones tipo Mashup.
Los recursos y operaciones sobre recursos contenidos en esta API deben ser intuitivos y fáciles de entender, y cumplir con los requisitos del protocolo HTTP.
El desarrollo REST también se denomina "desarrollo orientado a recursos", lo que demuestra que la abstracción de recursos es el contenido central del diseño de API RESTful. El proceso de modelado de API RESTful es similar al modelado orientado a objetos, con los sustantivos como núcleo. Estos sustantivos son recursos y cualquier concepto abstracto con nombre puede definirse como un recurso. El protocolo HTTP no es un protocolo de transmisión; en realidad proporciona una interfaz unificada para los recursos operativos. Cualquier operación sobre recursos debe asignarse a unos pocos métodos limitados de HTTP (los cuatro métodos comúnmente utilizados son GET/POST/PUT/DELETE, y los métodos PATCH/HEAD/OPTIONS, menos utilizados). Por lo tanto, el proceso de modelado de API RESTful puede considerarse como un proceso de modelado orientado a objetos con restricciones de interfaz unificadas.
De acuerdo con las disposiciones del protocolo HTTP, el método GET es seguro e idempotente, el método POST no es ni seguro ni idempotente (puede usarse como método comodín para todas las operaciones de escritura), métodos PUT, DELETE son todos inseguros pero idempotentes. Asigne razonablemente las operaciones de recursos a estos cuatro métodos, sin abusar de un determinado método (como el uso excesivo del método GET o POST), ni agregar tantas operaciones que los cuatro métodos de HTTP no sean suficientes.
2. Si encuentra que hay demasiadas operaciones en los recursos y el método HTTP no es suficiente, debería considerar diseñar más recursos. No hay nada de malo en diseñar una API RESTful con más recursos (y los URI correspondientes).
Esta API debe tener un acoplamiento flexible.
El diseño de RESTful API incluye tres niveles progresivos de menor a mayor: abstracción de recursos, interfaz unificada y controlador de hipertexto. Son estos tres niveles los que garantizan el acoplamiento flexible de las API RESTful.
3. Al diseñar una API orientada a Internet, el acoplamiento flexible se convierte en un requisito "imprescindible". Las API estrechamente acopladas son muy frágiles. Una vez publicadas, ni el servidor ni el cliente pueden seguir evolucionando. Especialmente en el lado del servidor, las interfaces publicadas no se atreven a cambiar en absoluto. Después de cambiarlas, casi todas las aplicaciones cliente ya no funcionarán correctamente. El estilo arquitectónico de REST es el antídoto para las API estrechamente acopladas. Este tema se puede discutir en profundidad, por lo que no lo abordaré aquí. Los lectores interesados pueden consultar "REST en la práctica".
El formato de expresión utilizado en esta API debe ser un formato común.
En la API RESTful, la operación de recursos se realiza mediante la transferencia de recursos entre el servidor y el cliente para completar la expresión. indirectamente. Las representaciones de recursos pueden tener muchos formatos y los formatos de representación de recursos diferirán en las respuestas y solicitudes. Los formatos de descripción de recursos comunes en las respuestas GET/POST incluyen HTML, XML y JSON; los formatos de descripción de recursos comunes en las solicitudes POST/PUT incluyen parámetros de formulario HTML estándar, XML y JSON.
4. Estos formatos de expresión comunes son muy fáciles de procesar y son compatibles con una gran cantidad de marcos y bibliotecas. Por lo tanto, a menos que existan requisitos muy razonables, normalmente no es necesario utilizar un formato privado personalizado.
Utilice códigos de estado de respuesta HTTP para expresar diversas situaciones de error
Los códigos de estado de respuesta HTTP son el mecanismo estándar utilizado para expresar situaciones de error en la interfaz unificada del protocolo HTTP. El código de estado de respuesta se divide en dos partes: código de estado y fase de motivo. Ambas partes son personalizables, también puede usar el código de estado estándar y personalizar solo la fase del motivo.
5. Si la llamada "API RESTful" devuelve una respuesta 200 OK a cualquier solicitud y devuelve información de error en el cuerpo del mensaje de respuesta, este enfoque obviamente no cumple con "garantizar la visibilidad de la semántica de la operación". " "Este es un requisito básico del estilo arquitectónico REST.
Esta API debe ser compatible con el almacenamiento en caché HTTP
6. Hacer un uso completo del almacenamiento en caché HTTP es fundamental para la escalabilidad de las API RESTful. El protocolo HTTP es una arquitectura en capas y se pueden insertar muchos componentes intermedios entre el agente de usuario en ambos extremos y el servidor de origen. El almacenamiento en caché se puede configurar en muchas ubicaciones de toda la cadena de comunicación HTTP. El protocolo HTTP tiene un buen mecanismo de almacenamiento en caché incorporado, que se puede dividir en dos conjuntos de mecanismos de almacenamiento en caché: modelo de caducidad y modelo de verificación. Si el diseñador de API no ha considerado cómo aprovechar el almacenamiento en caché HTTP, habrá muchos problemas con la escalabilidad de la API.