Eso es realmente REST API RPC? Roy Fielding parece pensar que sí
https://stackoverflow.com/questions/1164154
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Una gran cantidad de lo que yo creía que sabía sobre el descanso es al parecer mal - y no estoy solo. Esta pregunta tiene una larga lead-in, pero parece ser necesario porque la información es un poco dispersa. La pregunta real llega al final si ya está familiarizado con este tema.
Desde el primer párrafo de APIs REST necesidad de Roy Fielding hipertexto sea impulsada , que está bastante claro que cree que su trabajo está siendo ampliamente malinterpretado:
Estoy frustrado por el número de personas que llaman cualquier interfaz basada en HTTP una API REST. El ejemplo de hoy es el SocialSite API REST . Es decir RPC. Es un grito RPC. Hay tanto en la exhibición de acoplamiento que se le debe dar una calificación X.
Fielding pasa a enumerar varios atributos de una API REST. Algunos de ellos parecen ir en contra tanto una práctica común y asesoramiento en común SO y otros foros. Por ejemplo:
-
A API REST debe introducirse sin conocimiento previo más allá de la URI inicial (marcador) y un conjunto de tipos de medios estandarizados que sean apropiados para la audiencia deseada (es decir, que se espera para ser entendido por cualquier cliente que podrían utilizar el API). ...
-
Una API REST no debe definir los nombres de recursos fijos o jerarquías (un acoplamiento evidente de cliente y servidor). ...
-
Una API REST debe pasar la mayor parte de su esfuerzo descriptiva para definir el tipo (s) de medios utilizados para la representación de los recursos y la conducción de estado de la aplicación, o en la definición de nombres de relación prolongados y / o hipertexto habilitado margen para tipos de medios estándar existente. ...
La idea de "hipertexto" juega un papel central - mucho más que la estructura URI o lo que significan los verbos HTTP. "Hipertexto" se define en uno de los comentarios:
Cuando [Fielding] decir hipertexto, me refiero a la presentación simultánea de información y los controles de tal manera que la información se convierte en la potencialidad a través del cual el usuario (o autómata) obtiene opciones y selecciona las acciones. Hipermedia es sólo una expansión en qué texto significa incluir anclajes temporales dentro de un flujo de medios; la mayoría de los investigadores han bajado la distinción.
El hipertexto no tiene por qué ser HTML en un navegador. Las máquinas pueden seguir los vínculos cuando entienden el formato y las relaciones tipos de datos.
Estoy adivinando en este punto, pero por encima de los dos primeros puntos parecen sugerir que la documentación de la API para un recurso de Foo que tiene el siguiente aspecto conduce a estrecho acoplamiento entre el cliente y el servidor y no tiene lugar en un sistema REST.
GET /foos/{id} # read a Foo
POST /foos/{id} # create a Foo
PUT /foos/{id} # update a Foo
En su lugar, un agente debe ser obligado a descubrir las URIs para todos Foos, por ejemplo, la emisión de una petición GET / contra Foos. (Esos URIs pueden llegar a seguir el modelo anterior, pero ese no es el punto.) La respuesta utiliza un tipo de medio que es capaz de transmitir cómo acceder a cada elemento y qué se puede hacer con ella, dando lugar al tercer punto por encima . Por esta razón, la documentación de la API debe centrarse en la explicación de cómo interpretar el hipertexto contenida en la respuesta.
Además, se solicita cada vez que un URI a un recurso de Foo, la respuesta contiene toda la información necesaria para un agente para descubrir cómo proceder, por ejemplo, el acceso a los recursos asociados y de los padres a través de sus URIs, o mediante la adopción de medidas después de la creación / eliminación de un recurso.
La clave para todo el sistema es que la respuesta consiste en hipertexto contenida en un tipo de soporte que en sí transmite a las opciones de agente para proceder. No es a diferencia de la forma en que un navegador funciona para los seres humanos.
Sin embargo, esto es sólo mi mejor estimación en este momento particular.
Fielding publicó un seguimiento en el que respondió a las críticas de que su discusión era demasiado abstracto, carente de ejemplos, y la jerga ricos:
Otros intentarán descifrar lo que he escrito en formas que sean más directo o aplicables a cierta preocupación práctica de hoy. Yo probablemente no lo hará, porque estoy demasiado ocupado lidiando con el tema siguiente, la preparación para una conferencia, escribir otro estándar, viajar a algún lugar distante, o simplemente hacer las pequeñas cosas que me permiten Siento que tengo que ganaba mi cheque de pago.
Por lo tanto, dos preguntas sencillas para los expertos REST por ahí con una mentalidad práctica: ¿cómo interpretar lo que está diciendo y Fielding, ¿cómo poner en práctica cuando se documentan / implementación de APIs REST
Editar: esta pregunta es un ejemplo de lo difícil que puede ser aprender algo si usted no tiene un nombre de lo que estás hablando. El nombre en este caso es "Hipermedia como el motor de Estado de aplicación" (HATEOAS).
Solución
Creo que su explicación sobre todo lo cubre. URIs son identificadores opacos que debe, en su mayor parte, no se comunicarán más allá del marcador URI que es utilizado por el agente de usuario para acceder a la aplicación.
En cuanto a la documentación, esta pregunta se ha hecho unas cuantas veces. A documentar su tipo de soporte, junto con el hipervínculo controla que contiene (enlaces y formas), y el modelo de interacción si así lo desea (ver AtomPub).
Si el documento de los URI o cómo construir ellos, lo estás haciendo mal.
Otros consejos
Su interpretación me parece correcto. Creo que las restricciones de Fielding se pueden aplicar en la práctica.
Realmente me gustaría ver a alguien publicar algunos buenos ejemplos de cómo documentar una interfaz REST. Hay tantos ejemplos pobres, tiene algunos válidos para apuntar a los usuarios sería muy valiosa.
He estado buscando un buen ejemplo de una API escrita después de la HATEOAS y tenía problemas para encontrar uno (me pareció tanto la API SunCloud y AtomPub cosas de difícil aplicación a una situación "normal" API). Así que he intentado hacer un ejemplo realista en mi blog que siguió el consejo de Roy Fielding en lo que significa ser una correcta aplicación REST. Me pareció muy difícil llegar al ejemplo, a pesar del hecho de que es bastante simple en principio (simplemente confuso cuando se trabaja con una API en contraposición a una página web). Me sale lo que Roy estaba tomando problema con y estoy de acuerdo, es sólo un cambio de mentalidad para implementar adecuadamente para una API.
Tenga una mirada: API de ejemplo usando Resto
La única excepción a dar instrucciones sobre cómo construir URI es que es permisible para enviar una plantilla URI en la respuesta de hipertexto, con campos a ser sustituido automáticamente por el cliente, el uso de otros campos en el hipertexto. Esto no suele llegar a ahorrar mucho ancho de banda, aunque ya la compresión gzip se encargará de las partes repetidas de URIs lo suficientemente bien como para no molestar con esto.
Algunas buenas discusiones sobre el descanso y los HATEOAS relacionados:
Para los interesados, encontré un ejemplo detallado de HATEOAS en la práctica en la API Sun nube .
Lo que la mayoría de la gente consigue lo malo es que (al menos creo) en el mundo RESTO no documentar su "interfaz de descanso", lo que documento es un tipo de medio, independientemente de su servidor o servicio.
absolutamente correcta. Me gustaría tener en cuenta, además, que las plantillas que URI están perfectamente bien dentro de una aplicación REST, siempre y cuando los patrones son de documentos recibidos del servidor (OpenSearch ser un ejemplo adecuado). Para las plantillas de URI, a documentar dónde se están utilizando y cuáles son los marcadores de posición de espera en la plantilla son, pero no las propias plantillas. Ligeramente contrario a lo que dijo Wahnfrieden, esto no es una excepción.
Por ejemplo, en mi trabajo que tenemos un sistema de gestión de dominio interno, y el documento de servicio especifica dos plantillas URI: una para producir un mejor conjetura URI de un recurso de dominio, y otro para la construcción de un URI para consultar la disponibilidad del dominio. Es todavía posible a la página a través de la colección de dominios de averiguar lo que el URI de un dominio dado se, pero dada la inmensa cantidad de dominios que administra, esto no sería factible para el cliente, por lo que les da una manera de adivinar lo que el URI de un recurso de dominio podría ser una gran victoria en términos de facilidad de aplicación desde la perspectiva del cliente, y el ancho de banda del servidor de.
a su pregunta: Nuestra documentación normativa está expuesto recursos, el efecto de diferentes métodos sobre esos recursos, y los tipos de medios de representación utilizados y sus esquemas, y qué tipo de recursos de los URI en los representions apuntan a
También incluimos la documentación no normativo (informativo) que se ha unido a ella un descargo de responsabilidad de no leer demasiado en los URI se mencionan en el documento, que da ejemplos de interacciones cliente-servidor típicas. Esto pone a la documentación normativa bastante abstracto en términos concretos.
Creo que con el número de años que el descanso ha sido que hay ahora, los técnicos han llegado a un acuerdo con el concepto de un recurso y lo que realmente es o no es reparador.
De acuerdo con el Modelo de Madurez de Richardson, hay 4 niveles (0-3) que definen la forma en que su REST API es, con 3 significado una API REST de verdad, al igual que Roy Fielding destinado a ser.
El nivel 0 es cuando se tiene un punto de entrada URI -. Como jabón
Nivel 1 significa que el API es capaz de distinguir entre diferentes recursos, y tiene más de un punto de entrada -. Todavía huele a jabón
Nivel 2 es cuando se utiliza verbos HTTP - GET, POST, DELETE principalmente. Este es el nivel en el que se apoyan realmente entra en el cuadro.
En el nivel 3, de empezar a usar los controles de hipermedia para hacer su API realmente REST.
Enlaces sugeridos para la lectura adicional:
Vamos a suponer GET /foos/createForm se invoca para obtener los valores de los campos de formulario para el cual se debe proporcionar cuando vamos a crear POST /foos. Ahora bien, esta URL concreta es decir el 1 usado para crear Foos debe mencionar dentro de la respuesta de GET /foos/createForm como un enlace de acción de envío de acuerdo con la propuesta de Fielding, ¿verdad?
Entonces ¿cuál es el beneficio de las acciones de mapeo a verbos HTTP conocidas a las acciones, "Convención sobre el código / config" cosa está anulado.
