¿Qué es una buena API, proceso de diseño y principios de diseño?
La seguridad es un tema constante. Para los servicios web basados en WSDL y SOAP, contamos con especificaciones de seguridad como WS-Security para guiar la implementación de autenticación, autorización, gestión de identidad y otros requisitos de seguridad. Entonces, ¿existe alguna especificación madura o marco de implementación para la API RESTful? ¿Cómo garantizar la seguridad de la API RESTful?
¿Cómo controlar la versión de la API RESTful? Comparta cuál cree que es un enfoque práctico.
¿Son suficientes los verbos proporcionados en la especificación HTTP 1.1 para diseñar API RESTful? ¿Amplías tus verbos en proyectos reales? ¿En qué circunstancias se requiere la expansión?
¿Cuáles son las características más valiosas de la especificación JAX-RS 2.0 lanzada en mayo de este año para el diseño de RSTfulAPI? ¿Qué problemas se utilizan para resolver?
¿Puede recomendar un marco práctico de desarrollo de API RESTful a los lectores de InfoQ y explicar los motivos de su recomendación?
La especificación HTTP 2.0 se está formulando. ¿Cuáles son sus expectativas al respecto?
InfoQ: ¿Qué es una buena API RESTful? Creo que cada uno tiene su propio criterio para juzgar. Entonces, ¿qué características crees que debería tener una buena API RESTful?
Li Kun: 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 el Web.
Los navegadores son el cliente REST más común y versátil. Una buena API RESTful debería poder realizar todas las pruebas utilizando HTML del navegador (no es necesario utilizar un 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 el método PATCH/HEAD/OPTIONS, menos utilizado). 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 demasiadas operaciones hasta el punto de que los cuatro métodos de HTTP no sean suficientes.
Si descubre 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.
Al diseñar API para 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.
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.
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 el objetivo de "garantizar la visibilidad de la operación". semántica" Requisitos básicos para el estilo arquitectónico REST.
Esta API debe ser compatible con el almacenamiento en caché HTTP
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.
Li Jianye: En primer lugar, me gustaría explicar que el concepto de REST, generalmente lo entiendo como una arquitectura de estilo REST, pero la más reconocida en la práctica ahora es HTTP, y es una implementación de REST, por lo que la API RESTful también puede referirse de manera menos estricta a las API basadas en HTTP; por supuesto, incluso cuando no sea estricta, la API en sí debe esforzarse por seguir el estilo arquitectónico REST.
Creo que el punto más importante de una API RESTful debería ser "la menor información previa posible". Este es también mi criterio para juzgar una buena API RESTful.
Por ejemplo, los verbos HTTP. En la práctica, las personas a menudo pueden tener dificultades con el uso efectivo de los verbos HTTP, pero esto no es particularmente importante, a menos que comprenda el valor de hacerlo.
Lo más importante de los verbos HTTP es que es un comportamiento clarificado por el estándar, es decir, si nuestro "cliente" sigue la convención, no es necesario inventar nuevos verbos ni añadir "información previa". "; sin embargo, la llamada "información previa" está dirigida al cliente; para la API, es la persona que llama. Para algunos sistemas empresariales internos o algunos sistemas tradicionales, dado que los "recursos" son muy estables y las operaciones en el Los recursos también son muy estables, estos sistemas El "cliente que llama" no es el navegador sino otro sistema. En este momento, si se fuerza a corresponder al verbo HTTP, se convertirá en "información previa" adicional. No seré demasiado rígido con los verbos HTTP y formularé uno yo mismo. También es aceptable poner los verbos en parámetros; siempre que los verbos no cambien, el sistema seguirá siendo RESTful.
Otro ejemplo es el tipo de contenido en respuesta. Esto a veces los principiantes lo ignoran, pero en realidad es muy importante, porque generalmente involucra API para la colaboración entre sistemas y, a menudo, no se usa texto ordinario. usa json para expresar estructuras complejas, que es diferente de la comprensión predeterminada habitual (el valor predeterminado generalmente se considera texto/sin formato y texto/html), por lo que si olvida usar Content-Type para distinguir en la API, el procesamiento posterior de múltiples tipos de soporte de acceso de clientes pueden convertirse en una trampa (nos encontramos con este problema muchas veces). Y si verifica si desea agregar conocimientos previos desde el principio (el tipo de contenido predeterminado es simple o permite especificar el tipo de contenido), entonces esta dificultad se puede evitar.
Ding Xuefeng: En primer lugar, la interfaz unificada de HTTP debe usarse correctamente, como los verbos HTTP. Si todo POST se usa indiscriminadamente, obviamente hay margen de mejora;
En segundo lugar, los recursos tienen una granularidad adecuada que se puede juzgar a partir de tres aspectos: eficiencia de la red, tamaño de representación y facilidad de uso por parte del cliente;
Finalmente, el diseño de la representación, además del contenido principal de la declaración, así como el URI y los enlaces, son los criterios para juzgar la calidad de una API RESTful.
Ma Jun: En mi opinión, un buen estándar API es hacer un uso completo de las características del protocolo HTTP y tratar a HTTP como un protocolo de transferencia en lugar de un protocolo de transmisión. Incluyendo, entre otros: el uso de varios verbos de HTTP para aclarar las operaciones; incluida la negociación de contenido, que puede seleccionar el tipo de medio, el idioma, el juego de caracteres y el rendimiento de codificación más apropiados de un recurso de acuerdo con los parámetros proporcionados por el encabezado de la solicitud; códigos de retorno para describir varios estados. Pero, de hecho, he visto muchas API que afirman ser RESTful, tanto nacionales como extranjeras, y no muchas pueden cumplir estas condiciones. La API proporcionada por parse.com es una API RESTful relativamente buena que he visto y que puede usarse como ejemplo de referencia.
InfoQ: La seguridad es un tema constante. Para los servicios web basados en WSDL y SOAP, contamos con especificaciones de seguridad como WS-Security para guiar la implementación de requisitos de seguridad como autenticación, autorización y gestión de identidad. Entonces, ¿existe alguna especificación madura o marco de implementación para la API RESTful? ¿Cómo garantizar la seguridad de la API RESTful?
Li Kun: Garantizar la seguridad de las API RESTful incluye principalmente tres aspectos principales:
a) Autenticación de identidad para los clientes
b) Los datos confidenciales están cifrados y manipulados con para evitar manipulaciones
c) Autorización después de la autenticación de identidad
Existen varios métodos comunes para la autenticación de identidad del cliente:
En Agregar parámetros de firma a la solicitud
p>
Asigne una clave a cada parte de acceso y especifique un método de cálculo de firma. La solicitud de la parte de acceso debe incluir parámetros de firma. Este método es el más simple, pero debe garantizar el almacenamiento seguro de la clave de la parte de acceso y también prestar atención a prevenir ataques de repetición.
Su ventaja es que es fácil de entender e implementar, pero su desventaja es que necesita soportar la carga de almacenar la clave de forma segura y actualizarla periódicamente. No es lo suficientemente flexible y es difícil actualizar la clave y actualizarla. el algoritmo de firma.
Utilice el mecanismo de autenticación HTTP estándar
La autenticación HTTP básica tiene baja seguridad y debe usarse junto con HTTPS. La autenticación HTTP Digest se puede utilizar sola y tiene un nivel moderado de seguridad.
El mecanismo de autenticación HTTP Digest también admite la inserción de algoritmos de cifrado definidos por el usuario, lo que puede mejorar aún más la seguridad de la API. Sin embargo, la inserción de algoritmos de cifrado personalizados no se utiliza mucho en las API orientadas a Internet.
Este enfoque debe garantizar el almacenamiento seguro de la información triple "dominio de seguridad-nombre de usuario-contraseña" de la parte que accede, y también prestar atención a prevenir ataques de repetición.
Ventajas: Basado en estándares y ampliamente soportado (una gran cantidad de bibliotecas de cliente y servidor HTTP). La responsabilidad de la autenticación HTTP en el lado del servidor puede recaer en el servidor web (como Nginx), el servidor de aplicaciones (como Tomcat) y los marcos de seguridad (como Spring Security), que es transparente para los desarrolladores de aplicaciones. El mecanismo de autenticación HTTP (RFC 2617) incorpora muy bien el principio de diseño de "separación de preocupaciones" y mantiene la visibilidad de la semántica operativa.
Desventajas: Este tipo de mecanismo de contraseña basado en nombres de usuario simples no puede ser más seguro que los mecanismos basados en claves asimétricas (como los certificados digitales).
Utilice el protocolo OAuth para la autenticación de identidad
El protocolo OAuth es adecuado para autorizar que aplicaciones externas accedan a los recursos de este sitio. El mecanismo de cifrado es más seguro que la autenticación HTTP Digest. Cabe señalar que la autenticación OAuth y la autenticación HTTP Digest no se reemplazan entre sí. Sus escenarios aplicables son diferentes. El protocolo OAuth es más adecuado para proporcionar autorización para API orientadas al usuario final, como obtener información de Weibo perteneciente al usuario, etc. Si la API no está orientada a la dimensión del usuario final, como un servicio de almacenamiento como Qiniu Cloud Storage, este no es un escenario aplicable típico para el protocolo OAuth.
Para cifrar datos confidenciales y evitar la manipulación, los métodos comunes son:
Implementar infraestructura SSL (es decir, HTTPS), y la transmisión de datos confidenciales se basa en SSL.
Cifre solo algunos datos confidenciales (como el número de tarjeta y la contraseña de una tarjeta prepaga) y agregue algún número aleatorio como sal de cifrado para evitar que los datos sean manipulados.
La autorización después de la autenticación de identidad está controlada principalmente por la aplicación. Por lo general, se debe implementar algún tipo de mecanismo de autorización basado en grupos de usuarios de roles. Hay muchos marcos en esta área (como Spring Security), pero la mayoría de los equipos de desarrollo aún prefieren implementar funciones relacionadas ellos mismos.
Li Jianye: No creo que la seguridad sea un problema que deba considerarse para la API RESTful. De hecho, creo que son dos problemas ortogonales. Por supuesto, si utiliza una API RESTful para proporcionar autenticación, autorización y gestión de identidad, se puede considerar una relación entre ambas partes, pero esto no parece ser diferente de los problemas que se deben considerar en otros estilos de diseño de API, y no merece atención especial.
Sin embargo, a nivel de diseño específico, parece haber algunos problemas con los "puntos ortogonales" entre los dos, porque REST es un estilo arquitectónico que defiende el principio de independencia del estado, y la autenticación y autorización. Por lo general, se basan en soluciones de terceros, por lo que a menudo surgen problemas que violan las restricciones de estado. Por supuesto, esta dificultad tiene poco que ver con el problema original.
En cuanto al protocolo de la familia WS, no sé mucho al respecto y no puedo participar en la discusión.
Ding Xuefeng: Para las API RESTful, se pueden seguir utilizando medidas de seguridad comunes.
Por ejemplo, para evitar la manipulación, se pueden firmar todos los parámetros; para evitar ataques de repetición, se puede agregar un token único o un token válido por un período breve a la solicitud; el cifrado del contenido puede evitar la fuga de datos...; ataques, varias estrategias de limpieza de tráfico HTTP pueden seguir funcionando, porque se trata de una solicitud HTTP básica.
En términos de autorización y autenticación, OAuth 2.0 ha sido básicamente maduro y se ha utilizado ampliamente. Si es posible, es una buena opción conectarse a un sistema de cuentas de terceros, como Google y Facebook. Por supuesto, también hay varios candidatos nacionales.
Ma Jun: Personalmente creo que la seguridad de RESTful se divide en varios niveles. En situaciones con altos requisitos de seguridad, la seguridad de la capa de red se puede garantizar mediante protocolos de cifrado como HTTP y la seguridad. La capa de aplicación se puede garantizar a través de OAuth que implementa la autenticación, pero la autorización de acceso a recursos solo la pueden lograr las aplicaciones.
InfoQ: ¿Cómo controlar las versiones de las API RESTful? Comparta cuál cree que es un enfoque práctico.
Li Kun: Un enfoque relativamente simple y práctico es insertar directamente el número de versión en el URI. Esto permite que se ejecuten múltiples versiones de la API en paralelo.
Otro enfoque es agregar información de encabezado personalizado a la solicitud HTTP para indicar el número de versión utilizada. Sin embargo, este enfoque en realidad no es lo suficientemente amigable para el navegador y no se puede probar simplemente usando HTML del navegador.
Li Jianye: En la actualidad, la mejor manera es agregar información de la versión en el diseño de uri. Otros métodos no son tan prácticos como este.
Ding Xuefeng: Personalmente, creo que la mejor versión es que no existe una versión obvia. Al realizar cambios en los servicios publicados, intente que sean compatibles, incluidos URI, enlaces y compatibilidad con varias expresiones. Lo más importante es no destruir los clientes existentes al expandirse. Por ejemplo, si desea cambiar un parámetro, puede elegir que sea compatible con las entradas antiguas y nuevas, o mantener el parámetro anterior sin cambios y proporcionar un parámetro nuevo. Esto debe explicarse en el documento. No se recomienda el nuevo. Los usuarios continúan usando los parámetros anteriores.
Si se deben realizar cambios incompatibles, puede optar por marcar números de versión diferentes. En este caso, puede optar por agregar información de versión en la ruta o los parámetros. También hay una forma de agregar encabezados HTTP, pero será un poco inconveniente al llamar. Se recomiendan los dos primeros métodos.
Ma Jun: La actualización de la versión de la API RESTful debe ser lo más compatible posible con la versión anterior para garantizar que la API original pueda funcionar normalmente y pueda saltar a nuevos recursos a través de HTTP 301. Otro enfoque práctico es conservar el número de versión en la URL y proporcionar múltiples versiones para uso del cliente, como v1.rest.com o rest.com/v1/.
InfoQ: ¿Son suficientes los verbos proporcionados en la especificación HTTP1.1 para diseñar API RESTful? ¿Amplías tus verbos en proyectos reales? ¿En qué circunstancias se requiere la expansión?
Li Kun: Esta cuestión depende de cómo el diseñador ve y diseña los recursos. Si la abstracción de recursos se realiza bien, cualquier operación en un determinado recurso generalmente se puede asignar a las cuatro categorías CRUD. Las cuatro categorías CRUD están completas en la mayoría de los casos para los recursos operativos. Los cuatro métodos de HTTP GET/POST/PUT/DELETE son suficientes para las cuatro categorías de operaciones CRUD. La relación de mapeo es Create-POST/Retrieve-GET/Update-PUT/Delete-DELETE.
Por lo general, no elegimos crear nuestros propios verbos. Hacerlo requiere más costos de aprendizaje para los desarrolladores de los clientes. Si hay demasiadas operaciones definidas en un recurso, elegiremos dividir más recursos.
Li Jianye: Generalmente es suficiente. A veces, algunos escenarios "insuficientes" se deben a que no hemos diseñado recursos razonables, como operaciones por lotes.
Sin embargo, como se mencionó anteriormente, para algunos sistemas internos, tradicionales (y por lo tanto modelo estable y conocido), los proveedores de API y las personas que llaman tendrán sus propias listas de verbos fijos, y no hay necesidad de ser rígido en este caso. Además, no recomiendo expandir el verbo. Una vez que se expande el verbo, en realidad destruye lo que dije antes *"la menor información previa posible"*. Entonces, la diferencia de costo entre expandir el verbo y rediseñarlo no es así. grande. Por esta razón, recomiendo mantener los verbos iguales como sea posible, a menos que quieras rediseñar la tabla de verbos.
Ding Xuefeng: En circunstancias normales, los verbos HTTP de uso común son suficientes y no es necesario expandir los verbos usted mismo. De hecho, los más utilizados son GET, POST, DELETE y PUT, mientras que HEAD, OPTIONS y TRACE rara vez se utilizan. Si no puede encontrar un verbo adecuado por un tiempo, use GET para operaciones idempotentes seguras y POST para todo lo demás. Piénselo un poco al diseñar recursos.
Ma Jun: En mi proyecto actual, solo se utilizan los cuatro verbos POST, PUT, DELETE y GET.
InfoQ: ¿Cuál es la característica más valiosa de la especificación JAX-RS 2.0 lanzada en mayo de este año para el diseño de RSTfulAPI? ¿Para qué problemas se utiliza?
Li Kun: Bill Burke, líder del proyecto RESTEasy del marco de desarrollo REST, escribió un artículo presentando JAX-RS 2.0 el año pasado.
Estoy de acuerdo con el punto de Bill en el artículo Entre el contenido agregado de JAX-RS 2.0, las tres partes más importantes son:
a) API de cliente: utilizada para estandarizar JAX. Cómo desarrollar un cliente RS.
b) HTTP asincrónico del lado del servidor: se utiliza para implementar funciones push del lado del servidor sin depender de métodos de sondeo ineficientes.
c) Filtros e interceptores: se utilizan para separar preocupaciones y separar la autenticación, el registro y otra lógica de la lógica empresarial para lograr una mejor reutilización del código.
El contenido de estas tres partes es muy útil para los desarrolladores. El desarrollo de acuerdo con la especificación JAX-RS puede garantizar la portabilidad del código del lado del servidor y del lado del cliente.
Li Jianye: Personalmente presto atención a la parte de API asincrónica, principalmente porque habrá cada vez más servicios de transmisión, que requerirán mucho de ese soporte.
InfoQ: ¿Puede recomendar un marco práctico de desarrollo de API RESTful a los lectores de InfoQ y explicar los motivos de su recomendación?
Li Kun: No responderé esta pregunta en detalle. Los diferentes lenguajes de programación tienen diferentes marcos de desarrollo REST y diferentes niveles de soporte para REST. Los requisitos para desarrollar API RESTful son amplios y la gama de marcos de desarrollo disponibles también lo es. Mantener la diversidad es la base de un entorno ecológico próspero. Por ejemplo, Java tiene muchos marcos como Jersey, RESTEasy, Restlet, Apache CXF, que admiten la especificación JAX-RS, y Spring MVC, que no admite la especificación JAX-RS. Estos marcos actualmente están funcionando bien. No tengo preferencia por la elección del marco. Las mejores prácticas para el diseño de API RESTful deben ser universales y no necesariamente depender de un marco de desarrollo específico.
Li Jianye: Lo siento, no presto mucha atención a esto y no puedo recomendarlo. Sin embargo, puedo explicar por qué no estoy interesado en el marco de API RESTful.
REST, como estilo arquitectónico, tiene un gran impacto en el desarrollo de nuestro sistema, pero estos impactos generalmente se dan en la arquitectura (como la independencia del estado) o el diseño (como la identificación de recursos), por lo que una vez que llega a específico Después de la implementación, el trabajo principal básicamente ha terminado. En este momento, todo lo que el marco de desarrollo puede hacer es simplificar la programación (en comparación, algunos marcos también pueden desempeñar un papel en la guía del diseño), y porque RESTful abstrae los verbos, por lo que existe. No hay mucho trabajo relacionado con las especificaciones API a nivel de implementación, por lo que el valor del marco es aún menor.
Por supuesto, es imposible para nosotros desarrollar directamente en base a servlet/rakc/wsgi, pero los lenguajes de programación generales proporcionarán algunas estrategias simples de ruta/coincidencia de URL, y es suficiente para nosotros usarlas. estos. Además, algunos marcos pueden ayudarnos a generar soporte para todos los verbos, pero esto no es necesariamente algo bueno. Generalmente prefiero implementarlo bajo demanda: admitirlo después de usarlo, por lo que no es necesario prestar demasiada atención al desarrollo. soporte del marco para RESTful.
Ding Xuefeng: Como soy partidario de Spring y he estado usando Spring en el trabajo, tiendo a preferir Spring MVC al elegir un marco (no es que otros marcos no sean buenos, aquí hay algunas opiniones personales). ) componente subjetivo). Si debe elegir otro marco, también debe elegir un marco que pueda integrarse fácilmente con Spring. Si se ha utilizado Spring en el proyecto, entonces no hay razón para no elegir Spring MVC. En vista de la alta tasa de aparición actual de Spring en varios proyectos, creo que se elegirá Spring MVC en circunstancias normales.
En el modelo de madurez REST, la tercera capa es HATEOAS. Actualmente, Spring también proporciona el subproyecto Spring Hateoas, que ha realizado ciertas mejoras para admitir enlaces, recursos, etc.
Ma Jun: Actualmente estoy usando Spray en proyectos reales, que es un kit de herramientas REST/HTTP de código abierto y un paquete de E/S de red subyacente creado en Scala y Akka. Spray se caracteriza por ser liviano, asíncrono, sin bloqueo, basado en actores, modular y comprobable.
InfoQ: La especificación HTTP 2.0 se está formulando. ¿Cuáles son sus expectativas al respecto?
Li Kun: Mis expectativas incluyen dos aspectos: qué se debe hacer y qué no se debe hacer.
Qué debe hacer la especificación HTTP/2.0:
Seguir siendo compatible con el protocolo HTTP/1.1. Compatibilidad significa que los dos pueden coexistir y la aplicación cliente puede elegir libremente usar HTTP/2.0 o HTTP/1.1 según las capacidades del servidor, y el proceso de selección es transparente para la aplicación.
Mejorar la sintaxis de expresiones semánticas operativas en el protocolo HTTP (como interfaz unificada para recursos) para mejorar la eficiencia de transmisión de la red.
Mejor modularización, para que la implementación del protocolo HTTP/2.0 pueda modularizarse mejor. Las aplicaciones pueden seleccionar los módulos apropiados según sus necesidades, en lugar de todo o nada.
Abandonar algunas partes del protocolo HTTP/1.1 que rara vez se utilizan, como la canalización para enviar solicitudes.
Añade más verbos para adaptarse a otros escenarios además de CRUD.
Lo que no debería hacer la especificación HTTP/2.0:
El protocolo HTTP/2.0 no debería hacer que el mecanismo de cifrado de datos subyacente (es decir, SSL) sea una opción obligatoria.
El protocolo HTTP/2.0 no debe desviarse de las restricciones del estilo arquitectónico REST, especialmente para garantizar que la semántica de operación sea visible para los componentes intermedios.
En los dos aspectos anteriores, Roy Fileidng tuvo una vez un feroz debate con el diseñador del protocolo SPDY, Mike Belshe. Para más detalles, consulte: Roy Fielding habla sobre el protocolo SPDY de Google
Li Jianye: Con respecto a esto, no presto mucha atención a la especificación y no sé si habrá soporte para transmisiones. Actualmente, todo lo que sé es soporte simple en modo fragmentado, pero las transmisiones reales deben distinguir entre canales de datos y control. canales, incluso si es una distinción lógica, por lo que ha tenido un gran impacto directo en el estilo REST. Teniendo en cuenta el potencial de desarrollo futuro de los servicios de transmisión, espero particularmente que la industria avance en esta área.
Ding Xuefeng: HTTP 2.0 se basa en gran medida en SPDY de Google. En lo que a mí respecta, en primer lugar, espero que esta especificación pueda ser compatible con HTTP 1.1. Si los usuarios solo conocen 1.1, entonces 2.0 pueden. "degradarse" con gracia; en segundo lugar, espero que 2.0 pueda brindar un mejor rendimiento. SPDY aún ha realizado mejoras en este aspecto. Espero que HTTP 2.0 finalmente pueda continuar funcionando, espero que esta especificación pueda ir acompañada de una especificación; mejores prácticas cuando esté finalizado. Guíe correctamente a las personas para que utilicen HTTP 2.0 de manera razonable.
Ma Jun: No lo he investigado. Calculo que incluso si sale, 1.1 todavía tendrá un ciclo de vida largo y no será reemplazado pronto.