El diseño de recursos en una arquitectura basada en REST requiere una mentalidad completamente diferente a la del diseño de objetos en un lenguaje de programación orientado a objetos. Si bien hay algunos casos extremos que pueden ser difíciles de expresar con los métodos de HTTP dado un recurso con nombre nominal, tampoco es que OOP no tenga desafíos de diseño.
Los ejemplos que menciona son bastante fáciles de resolver con la restricción verbo + sustantivo de HTTP:
Reenviar solicitudes
Si se supone que el reenvío de la solicitud es invisible para el cliente, el servidor puede actuar como un proxy inverso, que es una forma estándar de operación e incluso una de las restricciones definitorias de REST.
- ¿Cuál es la mejor herramienta de notificación push web disponible para CS-Cart?
- Si desea crear una aplicación web pero no desea apoyar a un equipo de desarrollo, ¿pueden las opciones de código bajo ser lo suficientemente robustas como para admitir la aplicación?
- ¿Cuál es la aplicación empresarial de código abierto mejor escrita?
- ¿Cómo funciona New Relic?
- Sé algo de Python, y planeo desarrollar una aplicación web. ¿Cuáles son mis opciones tecnológicas?
Si el cliente necesita saber sobre el reenvío, puede hacerlo con un código de estado 3xx. Las solicitudes seguras, como GET , pueden usar 301 Moved Permanently o 302 Found, mientras que 303 See Other y 307 Temporary Redirect pueden usarse para métodos inseguros y / o no idempotentes como POST .
Eliminar entradas de tabla
DELETE /tables/customers?where=(age < 20 and sex = 'm') es una solicitud HTTP perfectamente válida. Es un patrón bastante común que de alguna manera u otra asigna el contenido de una base de datos a un recurso HTTP. La parte del lenguaje de consulta es un detalle de implementación, para el cual GraphQL, Falcor y OData Query Options son algunas de las muchas soluciones posibles.
Actualizar entradas de tabla
Aquí tienes al menos tres opciones posibles:
-
PUT /tables/customers/1reemplazará completamente el recurso del cliente. -
PATCH /tables/customers/1actualizará parcialmente el recurso del cliente. Consulte el parche JSON para ver ejemplos de sintaxis que se pueden usar para operar y realizar modificaciones en el “interior” de un recurso. -
POST /tables/customers/1con un cuerpo HTTP muy específico puede hacer lo que quiera; por ejemplo, identifique a otro cliente del que desea copiar todos los datos y que haya configurado el recurso identificado por el URI de solicitud.
TL; DR: si desea reemplazar las entradas por completo, use PUT . Si desea actualizarlos parcialmente, use PATCH . Si quieres hacer algo más especializado, usa POST . Además, el URI de solicitud se puede combinar con una cadena de consulta como en el ejemplo DELETE anterior.
Como puede ver, los ejemplos que proporciona son bastante fáciles de mapear en REST. Entonces, para responder a su pregunta: No, la restricción verbo + sustantivo no es demasiado simplista.
Como ya he dicho, hace que algunos casos extremos sean difíciles de modelar, pero los casos extremos son difíciles de modelar sin importar en qué arquitectura y paradigma intentes modelarlos. Puede que no sean los mismos en diferentes arquitecturas , pero todos tienen casos extremos que requieren un poco más de reflexión y no son inmediatamente aparentes o intuitivos para resolver.
