web-dev-qa-db-fra.com

REST pour les envois de fichiers)

Je dois créer une API REST pour un service de téléchargement de fichier qui permet à un utilisateur de:

  1. Ouvrir une session
  2. Télécharger un tas de fichiers
  3. Fermer la session

Et plus tard, revenez faire les choses avec les fichiers qu’ils ont chargés lors d’une session précédente.

Pour faciliter le traitement des données de chaque fichier et du contenu du fichier lui-même, voici le schéma d'URI que je pense utiliser:

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

Cela permettra aux métadonnées du fichier d'être traitées séparément du contenu du fichier. Dans ce cas, seul un GET est autorisé sur le fichier conten et le fichier métadonnées, et pour mettre à jour l'un ou l'autre, un nouveau fichier doit être PUT.

Est-ce que ça a du sens? Si non, pourquoi et comment cela pourrait-il être meilleur?

restfile-uploadapi-design
55
cdeszaq

Pourquoi avez-vous besoin de sessions? Est-ce pour des raisons d'authentification et d'autorisation? Si c'est le cas, j'utiliserais http basic avec SSL ou digest . En tant que tel, il n'y a pas de session de début ou de fin, car http est sans état et les en-têtes de sécurité sont envoyés à chaque demande.

Suggestion de ressource de téléchargement serait de mapper directement en tant que système de fichiers privé


# 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

Lors du téléchargement du contenu du fichier, vous utiliserez alors type de contenu en plusieurs parties .

Réponse révisée après commentaire

Je voudrais concevoir votre séparation souhaitée du contenu de fichier et de la charge utile en introduisant un lien (vers le contenu du fichier) dans la charge utile de téléchargement. Cela facilite la structure des ressources.

Représentation 'upload' resource:


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

Actions de ressources:


# 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
15
manuel aldana