Cómo diseñar una buena 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 una API RESTful? ¿Ampliarás tus verbos en proyectos reales? ¿En qué circunstancias es necesario ampliarlos?
¿Qué características de la especificación JAX-RS 2.0 lanzada en mayo de este año son más valiosas para diseñar API RSTful? ¿Qué problema se utiliza para resolver?
¿Puede recomendar un marco de desarrollo de API RESTful útil a los lectores de InfoQ y explicar los motivos de su recomendación?
La especificación HTTP 2.0 está en desarrollo, ¿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?
Kun Li: Una buena API RESTful debe tener las siguientes características:
La API debe ser compatible con el navegador y estar bien integrada en la Web, en lugar de ser incompatible con la Web.
Los navegadores son el cliente REST más común y versátil. Una buena API RESTful debería poder completar todas las pruebas utilizando un navegador y HTML (no se requiere lenguaje de programación). Las aplicaciones web front-end (aplicaciones RIA basadas en navegador, aplicaciones móviles, etc.) también pueden combinar fácilmente la funcionalidad de múltiples API RESTful para crear aplicaciones de tipo mashup.
Los recursos y sus operaciones contenidos en la API deben ser intuitivos y coherentes con los requisitos del protocolo HTTP.
El desarrollo REST también se denomina "desarrollo orientado a recursos", lo que indica que la abstracción de recursos es el núcleo del diseño de API RESTful. Estos sustantivos son recursos y cualquier concepto abstracto con nombre puede definirse como un recurso. El protocolo HTTP no es un protocolo de transporte. En realidad, proporciona una interfaz unificada para los recursos operativos. Cualquier operación en un recurso debe asignarse a un número limitado de métodos HTTP (los cuatro métodos comúnmente utilizados GET/POST/PUT/DELETE y los métodos menos utilizados PATCH/HEAD/OPTIONS). Por lo tanto, el proceso de modelado de RESTful API puede considerarse como un proceso de modelado orientado a objetos con restricciones de interfaz unificadas.
Según el protocolo HTTP, el método GET es seguro e idempotente, el método POST no es ni seguro ni idempotente (puede usarse como comodín para todas las operaciones de escritura) y los métodos PUT y DELETE son no seguro pero idempotente. Es razonable asignar operaciones sobre recursos a estos cuatro métodos. No abusará de un método (por ejemplo, abusará del método GET o del método POST), ni agregará demasiadas operaciones hasta el punto de que los cuatro métodos de HTTP El método es. no es suficiente.
Si descubre que hay demasiadas operaciones en un recurso y no suficientes métodos HTTP, debería considerar diseñar más recursos. No está de más diseñar una API RESTful con más recursos (y los URI correspondientes).
La 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 estas tres capas las que garantizan el acoplamiento flexible de una API RESTful.
El acoplamiento flexible se convierte en un requisito "imprescindible" al diseñar API orientadas a Internet. Las API estrechamente acopladas son muy frágiles y, una vez lanzadas, ni el lado del servidor ni el lado del cliente pueden seguir evolucionando.
Especialmente en el lado del servidor, la interfaz publicada no se atreve a cambiar. Después del cambio, casi todas las aplicaciones cliente no funcionarán correctamente de inmediato. El estilo arquitectónico REST es el antídoto para las API estrechamente acopladas. Este tema se puede analizar en profundidad, pero no lo ampliaremos aquí. Los lectores interesados pueden consultar "REST en acción".
El formato de representación utilizado en la API debe ser un formato común común
En una API RESTful, las operaciones sobre recursos se realizan pasando recursos entre el servidor y la expresión del cliente para completarse indirectamente.
Las representaciones de recursos en las respuestas GET/POST suelen estar en formatos HTML, XML y JSON; las representaciones de recursos en solicitudes POST/PUT suelen estar en parámetros de formulario HTML estándar, formatos XML y JSON.
Es muy fácil trabajar con estos formatos comunes y existe una gran cantidad de marcos y bibliotecas que los admiten. Por lo tanto, generalmente no es necesario utilizar un formato privado personalizado a menos que exista un requisito muy legítimo.
Utilice códigos de estado de respuesta HTTP para expresar varias condiciones de error
Los códigos de estado de respuesta HTTP son un mecanismo estándar para expresar condiciones de error en la interfaz unificada del protocolo HTTP.
Si la llamada "API REST" devuelve una respuesta 200 OK a cualquier solicitud y contiene información de error en el cuerpo de la respuesta, entonces obviamente esto no cumple con el requisito básico del estilo arquitectónico REST, que es para "garantizar la" visibilidad "de la semántica de la operación".
La API debe ser compatible con el caché HTTP
Aprovechar al máximo el almacenamiento en caché HTTP es fundamental para la escalabilidad de una API RESTful.
El protocolo HTTP es una arquitectura en capas donde se puede insertar una gran cantidad de componentes intermedios desde el agente de usuario hasta el servidor de origen en ambos extremos de la cadena. El protocolo HTTP es una arquitectura en capas donde puede insertar muchos componentes intermedios en cualquier extremo desde el agente de usuario hasta el servidor de origen, y en muchos puntos a lo largo de la cadena de comunicación HTTP puede configurar cachés. 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 considera aprovechar el almacenamiento en caché HTTP, habrá muchos problemas con la escalabilidad de la API.
Li Jianye: En primer lugar, me gustaría aclarar que el concepto de REST generalmente se entiende como una arquitectura de estilo REST, pero el enfoque más reconocido ahora es HTTP, que es una implementación de REST. por lo tanto, las API RESTful pueden denominarse de manera menos estricta API basada en HTTP; por supuesto, es flexible, si no estricta. -Por supuesto, la propia API debe esforzarse por seguir el estilo arquitectónico REST, aunque no sea estricto.
En mi opinión, el punto más importante de una API RESTful es "la menor información a priori posible", que también es mi criterio para juzgar una API RESTful excelente.
Por ejemplo, en aplicaciones reales, las personas a menudo pueden tener dificultades para usar los verbos HTTP de manera efectiva, pero esto no es particularmente importante a menos que comprenda el valor de hacerlo. Lo más importante del verbo HTTP es que es un comportamiento que está claramente establecido en el estándar, es decir, si nuestro "cliente" sigue el estándar, entonces es un comportamiento que no está claramente establecido en el estándar. "Cliente" sigue la convención, por lo que no es necesario inventar nuevos verbos y agregar "información previa". Sin embargo, la llamada "información previa" es para el cliente, para algunos sistemas empresariales internos o algunos tradicionales. En lo que respecta al sistema, dado que los "recursos" son muy estables y las operaciones sobre los recursos también son muy estables, el "cliente que llama" de estos sistemas no es el navegador, sino otro sistema. El "cliente que llama" para estos sistemas no es el navegador, sino otro sistema. En este momento, si corresponde por la fuerza a los verbos HTTP, se convertirá en "información previa" adicional. En este momento, no seré demasiado rígido con los verbos HTTP. Yo mismo desarrollaré un conjunto de verbos y los colocaré en los parámetros. Mientras el verbo no cambie, el sistema permanece RESTful.
Luego está el tipo de contenido en respuesta, que los principiantes a veces ignoran, pero en realidad es muy importante, porque las API que generalmente implican la colaboración entre sistemas a menudo no utilizan texto ordinario. con una estructura compleja de expresar, que es diferente de la comprensión predeterminada habitual (el valor predeterminado generalmente se considera texto/sin formato y texto/htmlplain y texto/html), por lo que si olvida distinguir por tipo de contenido en la API, soporte posterior Esto se convierte en una trampa para muchos tipos de acceso de clientes (nos encontramos con este problema muchas veces). Esta dificultad se puede evitar si compruebas desde el principio si has añadido conocimientos previos (el tipo de contenido predeterminado es texto plano o permite especificar el tipo de contenido).
Ding Xuefeng: En primer lugar, las interfaces unificadas HTTP, como los verbos HTTP, deben usarse correctamente. Si POST se especifica indiscriminadamente, obviamente hay margen de mejora;
En segundo lugar, Si la granularidad de los recursos es apropiada, se puede juzgar si la granularidad de los recursos es razonable desde tres aspectos: eficiencia de la red, representación, etc.
Majun: En mi opinión, un buen estándar API debería aprovechar las características del protocolo HTTP tanto como sea posible y tratar HTTP como un protocolo de transporte en lugar de un protocolo de transporte. Incluyendo, entre otros: el uso de varios verbos de HTTP para aclarar la operación; 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 del recurso de acuerdo con los parámetros proporcionados en el encabezado de la solicitud; diferentes códigos de retorno para describir varios estados. Pero, de hecho, he visto muchas API llamadas RESTful, tanto nacionales como extranjeras, y no muchas pueden cumplir estas condiciones. La API proporcionada por parse.com es la mejor API RESTful que he visto y puede usarse como referencia de ejemplo.
InfoQ: La seguridad es un tema eterno. 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 una especificación madura o un marco de implementación disponible para las API RESTful? ¿Cómo garantizar la seguridad de la API RESTful?
Kun Li: Hay tres aspectos principales para garantizar la seguridad de RESTful API:
a) Autenticación del cliente
b) Cifrado de datos confidenciales y prevención de manipulación
c) Autorización después de la autenticación
Existen varias formas comunes de autenticar al cliente:
Agregar parámetros de firma a la solicitud
Asigne una clave a cada parte que accede y especifique el método para calcular la firma. Requiere que se agreguen parámetros de firma a la solicitud de la parte que accede. Este es el método más simple, pero requiere un almacenamiento seguro de las claves del visitante y protección contra 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 claves de forma segura y actualizarlas periódicamente, y no es lo suficientemente flexible, lo que dificulta la actualización de claves y los algoritmos de firma.
Utilice el mecanismo de autenticación HTTP estándar
La autenticación HTTP básica es menos segura y debe usarse junto con HTTPS. La autenticación implícita HTTP se puede utilizar sola y proporciona un nivel moderado de seguridad.
La 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, no hay muchos casos de inserción de algoritmos de cifrado personalizados en API conectadas a Internet.
Este método requiere garantizar el almacenamiento seguro de la información triple "dominio de seguridad-nombre de usuario-contraseña" de la parte que accede y evitar ataques de repetición.
Ventajas: Basado en estándares, amplio soporte (una gran cantidad de bibliotecas de cliente y servidor HTTP). La responsabilidad de la autenticación HTTP del lado del servidor puede ser asumida por el servidor web (como Nginx), el servidor de aplicaciones (como Tomcat), el marco de seguridad (como Spring Security), y esto es transparente para el desarrollador de aplicaciones.
El mecanismo de autenticación HTTP (RFC 2617) incorpora bien el principio de diseño de "separación de preocupaciones" y mantiene la visibilidad de la semántica operativa.
Desventajas: Es poco probable que estos mecanismos simples basados en nombres de usuario y contraseñas sean más seguros que los mecanismos basados en claves asimétricas, como los certificados digitales.
Autenticación mediante el protocolo OAuth
El protocolo OAuth se utiliza para autorizar a aplicaciones externas a acceder a los recursos de este sitio web. El mecanismo de cifrado involucrado es más seguro que la autenticación implícita HTTP. Es importante tener en cuenta que la autenticación OAuth y la autenticación HTTP Digest no se reemplazan entre sí y son adecuadas para diferentes escenarios. El protocolo OAuth es más adecuado para proporcionar autorización para API orientadas al usuario final, como el acceso a información de Weibo perteneciente a los usuarios. Si la API no está orientada al usuario final, como un servicio de almacenamiento como Qiniu Cloud Storage, este no es un escenario de aplicación típico del protocolo OAuth.
Para cifrar datos confidenciales y evitar la manipulación, un enfoque común es:
Implementar infraestructura SSL (es decir, HTTPS), y la transmisión de datos confidenciales se basa en SSL.
Cifre solo una parte de los datos confidenciales (por ejemplo, número de tarjeta + contraseña de una tarjeta prepago) y agregue algún tipo de número aleatorio como sal de cifrado para evitar que los datos sean manipulados.
La autorización posterior a la autenticación está controlada principalmente por la aplicación. Normalmente se debería implementar algún tipo de mecanismo de autorización basado en roles y grupos de usuarios. Existen muchos marcos para esto (como Spring Security), pero la mayoría de los equipos de desarrollo aún prefieren implementar funciones relacionadas ellos mismos.
Jianye Li: No creo que la seguridad sea un problema que deba considerarse para las API RESTful. De hecho, creo que son dos problemas ortogonales. Por supuesto, si se utiliza una API RESTful para proporcionar autenticación, autorización y gestión de identidad, entonces habrá alguna relación entre los dos aspectos, pero esto no parece ser lo suficientemente diferente de lo que otros tipos de diseño de API deben considerar, por lo que No merece especial atención.
Pero a nivel de diseño, la "intersección" de los dos parece ser problemática, porque REST es un estilo arquitectónico que aboga por principios libres de estado, y la autenticación y autorización a menudo se basan en terceros. soluciones, por lo que a menudo ocurren violaciones de las restricciones estatales y no tengo una idea particular. No tengo ninguna idea especial sobre este problema. Por supuesto, esta dificultad tiene poco que ver con el problema original.
En cuanto al protocolo de la serie WS, no sé mucho al respecto y no puedo participar en la discusión.
Ding Xuefeng: Para las API RESTful, puede 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 corto período de tiempo a la solicitud; lograr la fuga de datos... .; Contra los ataques DDoS, varias estrategias de limpieza del 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 ampliamente utilizado. Si está disponible, es una buena opción para acceder a sistemas de cuentas de terceros (como los de Google y Facebook), aunque también existen varios sistemas de cuentas de candidatos nacionales.
Ma Jun: Personalmente creo que la seguridad de RESTful se divide en varios niveles. Cuando existen requisitos de seguridad, la seguridad de la capa de red se puede garantizar mediante protocolos de cifrado como HTTP y la seguridad de. la capa de aplicación se puede garantizar mediante la implementación de la autenticación OAuth, mientras que la autorización de acceso a recursos solo se puede lograr confiando en la aplicación.
InfoQ: ¿Cómo controlar la versión de la API RESTful? Comparta cuál cree que es un método práctico.
Li Kun: Un método simple y práctico es insertar el número de versión directamente en el URI, de modo que se puedan ejecutar múltiples versiones de la API en paralelo.
Otro enfoque es incluir un encabezado personalizado en la solicitud HTTP para indicar el número de versión en uso. Sin embargo, este enfoque no es lo suficientemente amigable para el navegador como para probarlo simplemente usando Navegador + HTML.
Jianye Li: En la actualidad, el mejor método 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 el mejor control de versiones es cuando no existe una versión obvia. Al realizar cambios en un servicio publicado, es importante intentar ser lo más compatible posible. Esto incluye la compatibilidad de URI, enlaces y varias representaciones diferentes y, lo más importante, no interrumpir los clientes existentes al ampliar. Por ejemplo, al cambiar un parámetro, puede elegir que sea compatible tanto con las entradas antiguas como con las nuevas, o dejar el parámetro antiguo sin cambios y proporcionar uno nuevo, pero debe documentar que no se recomienda que los nuevos usuarios continúen usando el anterior. parámetro.
Si se deben realizar cambios incompatibles, puede optar por marcar un número de versión diferente. Esto se puede hacer agregando información de la versión en la ruta o parámetro. Otra forma es agregar encabezados HTTP, lo cual es un poco inconveniente al llamar. Se recomienda utilizar los dos primeros métodos.
Ma Jun: Al actualizar la versión RESTfulAPI, intente ser compatible con la versión anterior. Para asegurarse de que la API original pueda funcionar correctamente, puede acceder a nuevos recursos a través de HTTP 301. Otro enfoque práctico es mantener el número de versión en la URL y proporcionar múltiples versiones para que las use el cliente, como v1.rest.com o rest.com/v1/, etc.
Pregunta de información: ¿Son suficientes los verbos proporcionados en la especificación HTTP 1.1 para diseñar una API RESTful? ¿Ampliarás tus verbos en proyectos reales? ¿En qué circunstancias es necesario ampliarlos?
Kun Li: Esta pregunta 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 el recurso generalmente se puede asignar a una de las cuatro categorías CRUD, y estas cuatro categorías básicamente pueden completar la operación en el recurso. El método HTTP GET/POST/PUT/DELETE es suficiente para cumplir con los requisitos de las cuatro categorías CRUD, y su relación de mapeo es Create-POST/Retrieve-GET/Update-PUT/Delete-DELETE.
Por lo general, no elegimos Crear sus propios verbos, ya que esto requerirá más costos de aprendizaje para el desarrollador del cliente. Si hay demasiadas operaciones definidas en un recurso, podemos optar por dividirlo más.
Jianye Li: En términos generales, es suficiente, pero a veces "no es suficiente". Esto se debe a que no diseñamos recursos de manera razonable, como las operaciones por lotes. Sin embargo, como dije antes, para algunos sistemas internos tradicionales (y, por lo tanto, estables y conocidos), los proveedores de API y las personas que llaman tendrán sus propias listas de verbos fijos, y no es necesario ceñirse a ellas. Además, no recomiendo ampliar la lista de verbos; una vez que la amplía, en realidad rompe lo que dije antes sobre "la menor información a priori posible" y la diferencia de costo entre ampliar la lista de verbos y rediseñar el verbo. La lista tampoco es grande. Con base en esta consideración, recomiendo mantener los verbos iguales como sea posible a menos que desees rediseñar la tabla de verbos.
Ding Xuefeng: En términos generales, hay suficientes verbos HTTP de uso común y no es necesario que los expanda usted mismo. De hecho, los más utilizados son GET, POST, DELETE y PUT. Básicamente, no hay demasiados HEAD, OPTIONS y TRACE. Si no puede encontrar un verbo adecuado en este momento, use GET cuando opere permisos de seguridad y POST para todo lo demás. Puede pensarlo un poco al diseñar recursos.
Majun: En mi proyecto actual, solo usé POST, PUT, DELETE y GET.
InfoQ: ¿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 RSTfulAPI? ¿Qué problema se utiliza para resolver?
Kun Li: Bill Burke, líder del proyecto del marco de desarrollo REST RESTEasy, escribió un artículo sobre JAX-RS 2.0 el año pasado.
Estoy de acuerdo con el punto de Bill en el artículo de que entre las nuevas características de JAX-RS 2.0, las tres partes más importantes son:
a) API de cliente: uso para estandarizar el desarrollo método del cliente JAX-RS.
b) HTTP asíncrono del lado del servidor: se utiliza para habilitar la funcionalidad de inserción del lado del servidor sin depender de un sondeo ineficiente.
c) Filtros e interceptores: se utilizan para separar las preocupaciones y la lógica (como la autenticación y el registro) de la lógica empresarial, lo que permite una mejor reutilización del código.
Las tres partes son muy útiles para los desarrolladores. El desarrollo siguiendo la especificación JAX-RS garantiza la portabilidad del código del lado del servidor y del lado del cliente.
Jianye Li: Personalmente me concentro más en la parte de API asíncrona, principalmente porque aparecerán 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 existen muchos marcos de desarrollo para elegir. Mantener la diversidad es la base de un ecosistema próspero. Java ya admite la especificación JAX-RS, como Jersey, RESTEasy, Restlet y Apache CXF, mientras que aquellos que no admiten la especificación JAX-RS incluyen Spring MVC y muchos otros marcos. Todos estos marcos están funcionando muy bien actualmente. No tengo preferencia por los marcos. Las mejores prácticas para el diseño de API RESTful deben ser universales y no necesariamente estar vinculadas a un marco de desarrollo específico.
Jianye Li: Lo siento, no valoro esto y no lo recomiendo, pero puedo explicar por qué no me gustan los marcos de API RESTful.
REST, como estilo arquitectónico, tendrá 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 el conocimiento de los recursos, la percepción de los recursos). Entonces, una vez involucrada 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 (por el contrario, algunos marcos también pueden desempeñar un papel en la guía del diseño), y gracias a la API RESTful. framework RESTful La función será un verbo abstracto, por lo que no hay mucho trabajo relacionado con las especificaciones API en el nivel de implementación, por lo que el valor del marco será aún menor.
Por supuesto, no podemos desarrollar directamente en base a servlet/rakc/wsgi, pero el lenguaje de programación general proporciona algunas estrategias simples de enrutamiento/coincidencia de URL, y es suficiente para nosotros usar estas estrategias. Además, algunos marcos pueden generar soporte verbal completo para nosotros, pero eso no es necesariamente algo bueno y, en general, prefiero implementarlo bajo demanda: usarlo y luego admitirlo, lo cual no es el caso para el desarrollo de marcos habilitados para RESTful. importante.
Ding Xuefeng: Dado que soy partidario de Spring y he estado usando Spring en el trabajo, preferiría Spring MVC en la elección del marco (no es que otros marcos no sean buenos, aquí hay algunos componentes subjetivos personales). ). Si tiene que elegir otro marco, elija uno que se integre fácilmente con Spring. Si ha utilizado Spring en su proyecto, no hay razón para no elegir Spring MVC. En vista de la alta visibilidad de Spring en varios proyectos, creo que elegirá Spring MVC en circunstancias normales.
La tercera capa del modelo de madurez REST es HATEOAS. Actualmente, Spring también proporciona el subproyecto Spring Hateoas y se han realizado algunas mejoras para respaldar enlaces, recursos, etc.
Majun: Actualmente estoy usando Spray, un kit de herramientas REST/HTTP de código abierto y un paquete IO de red de bajo nivel creado en Scala y Akka, en un proyecto del mundo real.
Spray es un modelo liviano, asincrónico, sin bloqueo, basado en roles, modular y comprobable.
InfoQ: La especificación HTTP 2.0 está en desarrollo, ¿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. La compatibilidad significa que los dos pueden coexistir, y las aplicaciones cliente pueden elegir libremente usar HTTP/2.0 o HTTP/1.1 según las capacidades del lado del servidor, y el proceso de selección es transparente para la aplicación.
Mejorar la sintaxis de las expresiones semánticas operativas en el protocolo HTTP (como una interfaz unificada para recursos) puede mejorar la eficiencia de la transmisión de la red.
Una mejor modularización permite modularizar mejor la implementación del protocolo HTTP/2.0. Las aplicaciones pueden seleccionar los módulos apropiados según sus necesidades, en lugar de todo o nada.
Elimine partes del protocolo HTTP/1.1 que se utilizan con poca frecuencia, como las solicitudes canalizadas.
Agregue más verbos para casos de uso distintos 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 operativa sea visible para los componentes intermediarios.
En estos dos aspectos, Roy Fileidng tuvo un acalorado debate con Mike Belshe, el diseñador del protocolo SPDY: Roy Fielding habla sobre el protocolo SPDY de Google
Li Jianye: Esta especificación tiene No recibió mucha atención, no sé si se admitirán transmisiones. En la actualidad, todo lo que sé es soporte simple para bloques, pero la transmisión real necesita distinguir entre canales de datos y canales de control, incluso distinciones lógicas. Esto afecta directamente el estilo REST. Considerando el potencial de desarrollo futuro de los servicios de medios de transmisión, somos particularmente. Esperamos con interés el progreso de la industria en esta área.
Ding Xuefeng: HTTP 2.0 se basa en gran medida en SPDY de Google. En lo que a mí respecta, primero espero que esta especificación pueda ser compatible con HTTP 1.1. Si los usuarios solo reconocen 1.1, entonces 2.0 puede ser elegante. " "Bajar de categoría"; en segundo lugar, espero que 2.0 ofrezca un mejor rendimiento.
Majun: No lo he investigado, pero creo que incluso si sale la versión 1.1, tiene un ciclo de vida largo y no será reemplazada pronto.