Estoy implementando un mini repositorio de documentos y archivos. Básicamente lo que quiero es un api REST para envío y descarga de documentos...
Pero ahí está la cosa. ¿Creeis que un servicio rest es lo más adecuado para el envío de documentos?. ¿Habéis trabajado con servicios que envien y reciban documentos?, ¿veis alguna alternativa mejor?.
Al final REST es una forma de organizar tu API, siguiendo los patrones y directrices que te recomiendan. El hecho de que el problema que intentes resolver sea relacionado con envío de documentos no tiene por qué verse afectado por usar el patrón REST.
Lo que quiero decir es que se puede resolver con REST y usando un único end-point, con muchos parámetros (que serían digamos las dos opciones más extremas que se me ocurren).
Personalmente yo opino que REST, además de ser mejor de cara al usuario final de tu API, que es lo que nos debería de importar, también es una buena forma, de cara al desarrollo, de organizar el código.
Muchas gracias por tu respuesta. Los servicios que quiero exponer (grosso modo) son dos: enviar un documento y recuperar la url de descarga del documento.
Lo que busco es no persistir los documentos en mi servidor y alojarlo en uno externo (existen gestores documentales... pero lo estoy haciendo en plan filosofía DIY con carácter didáctico).
El API hará precisamente eso:
- Permitir enviar documentos para que los gestione, persista y procese la aplicación.
- La aplicación devolverá la url de descarga de dicho documento (con algún metadato adicional, que sería prácticamente anecdótico).
Muy bien, en ese caso yo vería un recurso documentos con dos acciones:
- POST /documents: crearía el documento, y podría devolver la URL del documento en la cabecera Location (esto es una práctica cada vez más habitual). A esta acción le puedes pasar tantos parámetros como quieras para los metadatos
- GET /document/: obtiene el documento identificado por
El hecho de que se use almacenamiento local o remoto no afecta a esta definición de verbos y URLs, es más un detalle de implementación que de diseño.
Estoy implementando un mini repositorio de documentos y archivos. Básicamente lo que quiero es un api REST para envío y descarga de documentos...
Pero ahí está la cosa. ¿Creeis que un servicio rest es lo más adecuado para el envío de documentos?. ¿Habéis trabajado con servicios que envien y reciban documentos?, ¿veis alguna alternativa mejor?.
Un saludo.
02/07/2014 18:46
Al final REST es una forma de organizar tu API, siguiendo los patrones y directrices que te recomiendan. El hecho de que el problema que intentes resolver sea relacionado con envío de documentos no tiene por qué verse afectado por usar el patrón REST.
Lo que quiero decir es que se puede resolver con REST y usando un único end-point, con muchos parámetros (que serían digamos las dos opciones más extremas que se me ocurren).
Personalmente yo opino que REST, además de ser mejor de cara al usuario final de tu API, que es lo que nos debería de importar, también es una buena forma, de cara al desarrollo, de organizar el código.
¿Qué recursos vas a exponer?
03/07/2014 08:23
Muchas gracias por tu respuesta. Los servicios que quiero exponer (grosso modo) son dos: enviar un documento y recuperar la url de descarga del documento.
Lo que busco es no persistir los documentos en mi servidor y alojarlo en uno externo (existen gestores documentales... pero lo estoy haciendo en plan filosofía DIY con carácter didáctico).
El API hará precisamente eso:
- Permitir enviar documentos para que los gestione, persista y procese la aplicación.
- La aplicación devolverá la url de descarga de dicho documento (con algún metadato adicional, que sería prácticamente anecdótico).
Un saludo, y gracias por la respuesta :).
03/07/2014 10:14
- POST /documents: crearía el documento, y podría devolver la URL del documento en la cabecera Location (esto es una práctica cada vez más habitual). A esta acción le puedes pasar tantos parámetros como quieras para los metadatos
- GET /document/: obtiene el documento identificado por
El hecho de que se use almacenamiento local o remoto no afecta a esta definición de verbos y URLs, es más un detalle de implementación que de diseño.
Saludos!
04/07/2014 09:30
Genial tu respuesta. Nunca había oido lo de devolver la url del documento en la cabecera... pero parece buena idea.
¡Un saludo!.
12/07/2018 15:04