sirve - rest y json

REST-¿Qué significa exactamente interfaz uniforme?

Question

Wikipedia tiene:

Interfaz uniforme

La restricción de interfaz uniforme es fundamental para el diseño de cualquier servicio REST. [14] La interfaz uniforme simplifica y desacopla la arquitectura, lo que permite que cada parte evolucione de forma independiente. Los cuatro principios rectores de esta interfaz son:

Identificación de recursos.

Los recursos individuales se identifican en las solicitudes, por ejemplo, utilizando URI en sistemas REST basados ​​en la web. Los recursos en sí mismos están separados conceptualmente de las representaciones que se devuelven al cliente. Por ejemplo, el servidor puede enviar datos desde su base de datos como HTML, XML o JSON, ninguno de los cuales es la representación interna del servidor, y es el mismo recurso independientemente.

Manipulación de recursos a través de estas representaciones.

Cuando un cliente tiene una representación de un recurso, incluidos los metadatos adjuntos, tiene suficiente información para modificar o eliminar el recurso.

Mensajes auto-descriptivos

Cada mensaje incluye suficiente información para describir cómo procesar el mensaje. Por ejemplo, el analizador que se debe invocar se puede especificar mediante un tipo de medio de Internet (anteriormente conocido como tipo MIME). Las respuestas también indican explícitamente su capacidad de almacenamiento.

Hipermedia como motor de estado de aplicación (AKA HATEOAS)

Los clientes hacen transiciones de estado solo a través de acciones que son identificadas dinámicamente en hipermedia por el servidor (por ejemplo, por hipervínculos dentro de hipertexto). Excepto por puntos de entrada fijos simples a la aplicación, un cliente no asume que ninguna acción en particular esté disponible para recursos en particular más allá de los descritos en representaciones recibidas previamente del servidor.

Estoy escuchando una conferencia sobre el tema y el profesor ha dicho:

"Cuando alguien accede a nuestra API, si puede obtener un objeto de cliente y sabe que hay objetos de pedido, debería poder obtener los objetos de pedido con el mismo patrón del que obtuvo los objetos de cliente. Estos URI son va a parecerse el uno al otro ".

Esto me parece mal. No se trata tanto de cómo se ve el URI o de su coherencia, sino de la forma en que se utilizan los URI (identificar recursos, manipular los recursos a través de representaciones, mensajes auto-descriptivos y odio).

No creo que eso sea lo que signifique Uniform Interface. ¿Qué significa exactamente?

Answer 1

Ok, creo que entiendo lo que significa.

De la disertación de Fieldings:

La característica central que distingue el estilo arquitectónico REST de otros estilos basados ​​en la red es su énfasis en una interfaz uniforme entre los componentes (Figura 5-6). Al aplicar el principio de ingeniería de software de generalidad a la interfaz del componente, la arquitectura general del sistema se simplifica y se mejora la visibilidad de las interacciones.

Está diciendo que la interfaz entre componentes debe ser la misma. Es decir. entre cliente y servidor y cualquier intermediario, todos los cuales son componentes.

Answer 2

Su pregunta es algo amplia, parece que está pidiendo una reexpresión de las definiciones que tiene. ¿Estás buscando ejemplos o no entiendes algo específicamente establecido?

Estoy de acuerdo en que la línea:

Estos URI se van a parecer unos a otros

es fundamentalmente incorrecto Los URI no tienen que parecerse en nada para que se cumpla la restricción de interfaz uniforme. Lo que debe estar presente es una forma uniforme de descubrir los URI que identifican los recursos. Esta forma uniforme es única para cada tipo de mensaje, y debe haber algún formato acordado. Por ejemplo, en HTML, un recurso de documento enlaza con otro a través de una etiqueta simple:

<a href="URI of related resource" rel="defined relationship">fallback relationship</a>

Los servidores HTTP devuelven html como un tipo de recurso text / html que los navegadores tienen una forma acordada de analizar. La etiqueta de anclaje es el control de hipermedia (HATEOAS) que tiene el identificador único para el recurso relacionado.

El único punto que no fue cubierto fue la manipulación. HTML tiene otro ejemplo impresionante de esto, la etiqueta de formulario:

<form action="URI" method="verb">
  <input name=""></input>
</form>

nuevamente, el navegador sabe cómo interpretar esta metainformación para definir una representación del recurso en el que se actuó en el URI. Desafortunadamente, HTML solo te permite GET y POST para verbos ...

más comúnmente en un servicio basado en JOSN, cuando recuperas un recurso de Persona, es fácil manipular esa representación y luego PUT o PATCHAR de nuevo a su URL canónica. No se necesita ningún conocimiento preexistente del recurso para modificarlo. Ahora, cuando escribimos el código del cliente, nos envolvemos con la idea de que, de hecho, necesitamos conocer la forma antes de consumirla ... pero eso es solo para hacer que nuestros analizadores sean eficientes y fáciles. Podríamos hacer analizadores que analicen el significado semántico de cada parte de un recurso y lo modifiquemos interpretando la intención de la modificación. IE: un comando para hacer que la persona 10 años mayor analice el recurso en busca de la edad, identifique la edad y luego agregue 10 años a ese valor, y luego envíe ese recurso al servidor. ¿Es más fácil tener un código que espere que la edad esté en una ruta JSON de $ .age? Absolutamente ... pero no es específicamente necesario.

Answer 3

Usar interfaces para desacoplar las clases de la implementación de sus dependencias es un concepto bastante antiguo. Me sorprende que no hayas oído hablar de eso ...

Mediante REST, utiliza el mismo concepto para desacoplar al cliente de la implementación del servicio REST. Para definir una interfaz de este tipo (contrato entre el cliente y el servicio), debe utilizar estándares. Esto se debe a que si desea una red de servicios REST de Internet, debe aplicar conceptos globales, como estándares para que se entiendan entre sí.

• Identificación de recursos: utiliza el estándar URI (IRI) para identificar un recurso. En este caso un recurso es un documento web.

• Manipulación de recursos a través de estas representaciones: utiliza el estándar HTTP para describir la comunicación. Entonces, por ejemplo, GET significa que desea recuperar datos sobre el recurso identificado por URI. Puede describir una operación con un método HTTP y un URI.

• Mensajes autodescriptivos: utiliza tipos MIME estándar y vocabs RDF (estándar) para que los mensajes sean autodescriptivos. Por lo tanto, el cliente puede encontrar los datos al verificar la semántica y no tiene que conocer la estructura de datos específica de la aplicación que utiliza el servicio.

• Hipermedia como el motor del estado de la aplicación (AKA HATEOAS): se usan hipervínculos y posiblemente plantillas URI para desacoplar al cliente de la estructura URI específica de la aplicación. Puede anotar estos hipervínculos con semántica, por ejemplo, las relaciones de enlace de la IANA, para que el cliente entienda lo que significan.

Answer 4

"Interfaz uniforme" en realidad significa que las respuestas del servidor deben anunciar las acciones y recursos disponibles. En otras palabras, los recursos de consulta deben permitir al cliente solicitar otras acciones y recursos sin conocerlos de antemano.

JSON-API especificación JSON-API ofrece un buen ejemplo:

{
  "links": {
    "self": "http://example.com/articles",
    "next": "http://example.com/articles?page[offset]=2",
    "last": "http://example.com/articles?page[offset]=10"
  },
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON API paints my bikeshed!"
    },
    "relationships": {
      "author": {
        "links": {
          "self": "http://example.com/articles/1/relationships/author",
          "related": "http://example.com/articles/1/author"
        },
      },
      "comments": {
        "links": {
          "self": "http://example.com/articles/1/relationships/comments",
          "related": "http://example.com/articles/1/comments"
        }
      }
    },
    "links": {
      "self": "http://example.com/articles/1"
    }
  }]
}

Con solo analizar esta respuesta única, un cliente sabe:

1. lo que estaba preguntando (artículos)
2. ¿Cómo son los artículos estructurados (id, título, autor, comentarios)?
3. cómo recuperar objetos relacionados (es decir, autor, lista de comentarios)
4. que hay más artículos (10, según la longitud de respuesta actual y los enlaces de paginación)

Espero que esto ayude.
Para aquellos apasionados por el tema, ¡recomiendo encarecidamente leer la disertación de Thomas Fielding !