http - secure a rest api

HATEOAS Rel-¿Alguna norma aún?

Question

Estoy empezando a escribir una implementación de cliente para un WebAPI que estoy construyendo actualmente. La API ya emplea HATEOAS, así que estoy escribiendo el cliente en consecuencia. Estoy usando RestSharp como la base para el cliente.

Al Cliente se le pasa la URL de la base de API en el momento de la construcción (" https://myapi/start "), a la que se le envía una solicitud y luego se le pasa un conjunto de uris para otros recursos disponibles: autorización (" https://myapi/authorize ") y solicite tokens de acceso (" https://myapi/tokens ") para autorizarlo a llamar a recursos seguros en la api.

La pregunta es: ¿hay algún estándar elaborado aún para los requisitos rel = "" en el hipermedia devuelto?

Answer 1

Antes de seguir hablando sobre los estándares de HATEOAS, quiero enfatizar que hay tres conceptos principales en una API que implementa HATEOAS (hoy en día también conocida como API de Hypermedia):

• El protocolo HTTP. Tienes que respetar sus restricciones al usar verbos y códigos de retorno. También debe conocer el papel de los encabezados, especialmente Content-type , y las sutilezas como la idempotencia de algunos verbos. Ver RFC 2616 para más
• La estructuración URI. Lo que solo debe proporcionar información sobre la orientación de un recurso y evitar datos contextuales. Ejemplos malos conocidos son, por ejemplo, incluir language /en/ , version /v01/ , format /json/ o incluso verbos /do-something/ en el URI. Más sobre eso en RFC 3986 y en las pautas de REST.
• Datos contextuales, que se pueden encontrar en el cuerpo, parámetros de solicitud o en los encabezados

Los desarrolladores de bibliotecas REST tienen pautas sólidas para seguir con respecto a los URI y HTTP, pero carecen de un estándar universal sobre los datos contextuales y cómo se combinan con los datos de la aplicación en el cuerpo JSON de las solicitudes.

Esta es la razón por la que el esfuerzo de estandarización en torno a HATEOAS consiste principalmente en hacer especificaciones sobre el media-type . Hay varios unos por ahi

• JSON HAL (ca 2012), como lo describe Mark Jones, es el más conocido
• Colecciones + JSON (ca 2013), que no recibió mucha atención
• Verbose (ca 2014) intentó unificar todos los otros esfuerzos, pero solo es conocido por especialistas
• Siren (ca 2017) tiene alrededor de 1k estrellas en github
• JSON: API (ca 2015 pero todavía en progreso) es la referencia actual, con muchas implementaciones para su versión 1.0 y el soporte de Steve Klabnik, quien fue el autor de una gran cantidad de contenido sobre el tema.

Con respecto a su pregunta original, consulte HERE para ver las declaraciones de JSON:API sobre los enlaces de recursos relacionados.

Espero que esto ayude a cualquiera que tenga las mismas preocupaciones en 2019.

Answer 2

Creo que el lenguaje de aplicación de hipertexto (HAL) es un borrador de norma: intentar estandarizar estos enlaces entre hipermedia.

Este es un enlace al borrador de la especificación JSON http://tools.ietf.org/html/draft-kelly-json-hal-03

La especificación HAL impone que "href" cumpla con el "IRI de destino" definido en la especificación de enlace web (RFC 5988)

Hay una implementación XML de HAL usando C # aquí https://github.com/tavis-software

El mismo repositorio de GitHub anterior también contiene un ejemplo de implementación .Net de RFC 5988.

Answer 3

Este documento estándar RFC5988 propuesto por IETF describe los diferentes tipos de relación de enlace y usos propuestos. Se enfoca en la especificación del encabezado de enlace HTTP, pero incluye una discusión de otros tipos de relaciones de enlace. Al igual que algunos RFC (¿la mayoría?), Leerlos puede dejarte más confundido que cuando empezaste, pero a la larga vale la pena el esfuerzo. ¿Contestaría qué poner entre las comillas dobles en tu pregunta? Probablemente no, pero al menos tendrás algunas ideas para guiar tus elecciones.

Answer 4

HAL parece muy interesante por cierto.

Para cualquier otra persona que busque este tema o HATEOAS, el navegador HAL es una necesidad. Echa un vistazo en el siguiente enlace:

El navegador Hal en Heroku

Answer 5

La especificación de enlace web, RFC5988 , como se ha señalado en otra respuesta, define algunos tipos diferentes de relaciones de enlace. Pero también le indica a la IANA que cree un registro de relaciones de enlaces y que permita registros de relaciones de enlaces adicionales. Ese registro, que es la lista definitiva de relaciones de enlace público, está disponible en iana.org/assignments/link-relations y se actualizará a medida que se registren nuevas relaciones.

Las relaciones de uso común en las API de HTTP incluyen:

• start (los puntos de cada recurso vuelven al punto de inicio de la API)
• item (puntos de una colección a un elemento, por ejemplo, de una página de usuario de Twitter a un tweet)
• collection (reverso del item )
• previous (estos cuatro siguientes son para recursos paginados, por ejemplo, colecciones o artículos de varias páginas)
• next
• first
• last
• create-form (puntos de una colección a un recurso que describe cómo crear nuevos elementos de colección, por ejemplo, un formulario de "Nuevo elemento" o HTML o formulario de XForms)
• edit-form (puntos de un elemento a un formulario para editar ese elemento, por ejemplo, un botón Editar Tweet)

Si su relación deseada no está cubierta por nada en esa lista, su relación debe ser una URI . Además, se recomienda hacer que URI sea una URL http no referenciable en un dominio bajo su control para que los clientes de API puedan consultar la documentación de la relación, por ejemplo, http://www.example.com/link-relations#tweets . Por lo general, el punto de inicio de la API será una lista de colecciones, cada una con una relación de enlace personalizada que describe qué tipo de recurso contiene cada colección.