Uso de verbos LINK y UNLINK HTTP en una API REST

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 manera RESTful?

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

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

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

Gracias

Answer 1

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

He encontrado que hay tres tipos de clientes:

1. Aquellos que sólo admite GET y POST, tomando sus señales de elemento de HTML <form>.
2. Los que solo admiten GET, PUT, POST y DELETE. Estos toman sus señales de las API tipo CRUD y RPC, pretendiendo ser REST.
3. Aquellos 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.

Ya que actualmente desarrollamos nuestros clientes en el local que no tienen este problema, pero he mirado en él y tuvo en cuenta los pros y los contras antes de definir mi API, en caso de que queríamos para permitir que terceros clientes del partido. Mi solución (ya que necesitábamos para apoyar clientes HTML sin JavaScript de todos modos) era permitir POST para anular el método suministrando un campo _METHOD (application/x-www-form-urlencoded) y luego tener mi función post() en la palma de la parte posterior a la función apropiada para la intención Método HTTP De esta forma, cualquier cliente en el futuro que esté, por ejemplo, en la clase 2 anterior, puede usar PUT y DELETE pero envolver PATCH, LINK y UNLINK en una solicitud POST. Obtienes lo mejor de ambos mundos: métodos enriquecidos de clientes que lo admiten y, aún así, admiten clientes de baja calidad mediante el túnel POST.