Pregunta

como todo el mundo puede haber notado, hay gran cantidad de falsos / rudimentaria REST API en la naturaleza (que implementar un HTTP-API y llame a reposar sin seguir el requisito de hipertexto-como-el-motor-de-la aplicación de estado , que condujo a la famosa diatriba de Roy T. Fielding , el hombre que primero se especifica el RESTO-paradigma).

He sido incapaz de encontrar ejemplos prácticos de una aplicación verdaderamente REST-hipertexto impulsado, junto con las definiciones de tipos de medios específicos de aplicación asociados para las transiciones de estado.

¿Hay ejemplos de acceso público de tales implementaciones?

¿Fue útil?

Solución

No es una implementación en el sentido de la ejecución de código, pero me gusta mucho el artículo " ¿Cómo conseguir una taza de café " en InfoQ. En él se describe el proceso de ordenar un café en Starbucks como un protocolo REST. Esto va más allá de la típica "todo es un recurso" descanso artículo introductorio y se centra en HATEOAS. Muy recomendable.

Otros consejos

¿Qué hay de la Sun nube API? Desde la introducción:

  

El API presupone ninguna estructura particular en el espacio URI. El punto de partida es un URI, suministrado por el proveedor de servicio en la nube, que identifica la nube en sí. representación de la nube contiene URIs de los otros recursos en la nube, y también para las operaciones que pueden realizarse sobre ellos (por ejemplo el despliegue y puesta en máquinas virtuales).

El historia de fondo también podrían ser útiles.

RESTO API se basa en HATEOAS que incluye enlaces como parte de los recursos.

no es el sosiego de la API, Sol, Nube realidad abordada en el punto cuarto de Roy:

  

A REST API no debe definir los nombres de recursos fijos o jerarquías (un acoplamiento evidente de cliente y servidor). Los servidores deben tener la libertad de controlar su propio espacio de nombres. En su lugar, permiten que los servidores a instruir a los clientes sobre cómo construir apropiada URI, tal como se hace en los formularios HTML y plantillas URI, definiendo dichas instrucciones dentro de los tipos de medios y rel. [Incumplimiento aquí implica que los clientes están asumiendo una estructura de recursos debido a la información fuera de banda, tales como un estándar específico de dominio, que es el equivalente basado en datos de acoplamiento funcional de RPC].

Ejemplo 1 nombres de recursos fijos en un heirachy definido:

A partir de la API de Sun de la nube: "... la representación de una VCC incluirá representaciones de los grupos de los que habitan en ella, que a su vez incluyen representaciones de las máquinas virtuales dentro de cada grupo"

Ejemplo 2 fuera-de-banda de información, tal como un estándar específico de dominio:

Hay que tener el contenido wiki-página (fuera de banda de información) para saber que el "mecanismo de comunicación de recursos" para el campo de los recursos de la nube "URI" es GET.

Me di cuenta de esto se le preguntó hace un tiempo, pero me tomó una puñalada en la demostración de un flujo API REST "adecuado" para un ejemplo sencillo. Traté de seguir las reglas de Roy como REST - tal vez podría ayudar: Ejemplo utilizando REST

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top