tutorial - Usando los verbos LINK y UNLINK HTTP en una API REST

rest api tutorial español

Question

Actualmente estoy trabajando en la implementación de una API REST. Tengo un modelo de recursos con una gran cantidad de relaciones entre los recursos individuales.

Mi pregunta es: ¿cómo se vinculan dos recursos existentes entre sí (establecer una relación) de una manera REST?

Una solución que encontré fue el uso de los verbos LINK y UNLINK HTTP. El consumidor de API podría vincular dos recursos mediante LINK y siguiendo el URI: / resource1 /: id1 / resource2 /: id2.

El problema con esta solución es la falta de soporte para los verbos LINK y UNLINK. Ni http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html o http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol mencionan los verbos, y parecen estar en gran parte "olvidados". Sin embargo, el RFC 2068 original establece que existen.

Realmente me gusta esta solución. Sin embargo, me temo que muchos consumidores / clientes de API no podrán lidiar con la solución debido a la falta de soporte para LINK / UNLINK. ¿Es esta una solución aceptable o existen soluciones mejores y / o más elegantes para vincular los recursos existentes en una API RESTful?

Gracias

Answer 1

Utilizo LINK y UNLINK en mi aplicación web (a medida, interna de la empresa). Utilizo http://tools.ietf.org/html/draft-snell-link-method como referencia de mi implementación.

Encontré que hay tres tipos de clientes:

1. Aquellos que solo admiten GET y POST , tomando sus claves del elemento <form> de HTML.
2. Aquellos que solo soportan GET , PUT , POST y DELETE . Estos toman sus señales de las API de tipo CRUD y RPC que pretenden ser REST.
3. Los que permiten cualquier método. La publicación de PATCH como RFC oficial ha aumentado la cantidad de estos, al igual que el crecimiento de WebDAV, aunque a veces los clientes de categoría 2 también admiten PATCH .

Como actualmente desarrollamos a nuestros clientes en la empresa, no tenemos este problema, pero lo he investigado y he considerado los pros y los contras antes de definir mi API, en caso de que quisiéramos permitir que terceros clientes. Mi solución (ya que necesitábamos admitir clientes HTML sin Javascript de todos modos) era permitir que POST anulara el método al proporcionar un campo _METHOD ( application/x-www-form-urlencoded ) y luego tener mi función post() en la parte post() finalice la palma de la mano con la función apropiada para el método HTTP deseado. De esa manera, cualquier cliente en el futuro que se encuentre en, digamos, la clase 2 anterior, puede usar PUT y DELETE pero envolver PATCH , LINK y UNLINK en una solicitud POST . Obtiene lo mejor de ambos mundos: métodos enriquecidos de los clientes que lo admiten, y aún así admite clientes de baja calidad a través del túnel POST.