patterns - restful api designing guidelines the best practices

Diseño REST para cargas de archivos

Question

Necesito hacer una API REST para un servicio de carga de archivos que le permita a un usuario:

1. Abra una sesión
2. Suba un montón de archivos
3. Cierra la sesión

Y luego, vuelva y haga cosas con los archivos que cargó en una sesión anterior.

Para facilitar el manejo de datos sobre cada archivo y tratar con el contenido del archivo en sí, este es el esquema URI que estoy pensando en usar:

/sessions/
/sessions/3
/sessions/3/files
/sessions/3/files/5
/sessions/3/file/5/content
/sessions/3/file/5/metadata

Esto permitirá que los metadatos del archivo se traten por separado del contenido del archivo. En este caso, solo se permite un GET en el contenido del archivo y los metadatos del archivo, y para actualizar cualquiera de ellos, se debe poner un archivo nuevo.

¿Esto tiene sentido? Si no, ¿por qué y cómo podría ser mejor?

Answer 1

¿Por qué necesitas sesiones? ¿Es por razones de Autenticación y Autorización? Si es así, usaría http basic con SSL o digest . Como tal, no hay sesión de inicio o fin, porque http es apátrida y los encabezados de seguridad se envían en cada solicitud.

Sugerencia de recurso de carga sería mapear directamente como sistema de archivos privado

# returns all files and subdirs of root dir
GET /{userId}/files
GET /{userId}/files/file1
GET /{userId}/files/dir1
# create or update file
PUT /{userId}/files/file2

Al cargar el contenido del archivo, utilizará el tipo de contenido multiparte .

Respuesta revisada después del comentario

Diseñaría su separación deseada de contenido de archivo y carga mediante la introducción de un enlace (a contenido de archivo) dentro de la carga útil de carga. Alivia la estructura de los recursos.

Recurso de "carga" de representación:

{
"upload-content" : "http://storage.org/2a34cafa" ,
"metadata" : "{ .... }"
}

Acciones de recursos:

# upload file resource
POST /files
-> HTTP 201 CREATED
-> target location is shown by HTTP header ''Location: /files/2a34cafa
# /uploads as naming feels a bit more natural as /files
POST /sessions/{sessionId}/uploads
-> HTTP 201 CREATED
-> HTTP header: ''Location: /sessions/{sessionId}/uploads/1
-> also returning payload
# Updating upload (like metadata)
/PUT/sessions/{sessionId}/uploads/1