Nous développons un serveur avec l'API REST, qui accepte et répond avec JSON. Le problème est, si vous devez télécharger des images du client au serveur.
Remarque: et je parle aussi d'un cas d'utilisation où l'entité (utilisateur) peut avoir plusieurs fichiers (carPhoto, licensePhoto) et également avoir d'autres propriétés (nom, email ...), mais lorsque vous créez un nouvel utilisateur, vous ne N'envoyez pas ces images, elles sont ajoutées après le processus d'inscription.
Les solutions dont j'ai connaissance, mais chacune d'elles présente des défauts
1. Utilisez multipart / form-data au lieu de JSON
bon : les requêtes POST et PUT sont aussi RESTful que possible, elles peuvent contenir des entrées de texte avec un fichier.
inconvénients : Ce n'est plus JSON, ce qui est beaucoup plus facile à tester, déboguer, etc. par rapport à multipart / form-data
2. Autoriser la mise à jour de fichiers séparés
La requête POST pour créer un nouvel utilisateur ne permet pas d'ajouter des images (ce qui est correct dans notre cas d'utilisation comme je l'ai dit au début), le téléchargement des images se fait par requête PUT en multipart / form-data vers par exemple / users / 4 / carPhoto
bon : tout (sauf le fichier qui se télécharge) reste en JSON, il est facile de tester et de déboguer (vous pouvez enregistrer des requêtes JSON complètes sans avoir peur de leur longueur)
inconvénients : Ce n'est pas intuitif, vous ne pouvez pas POST ou PUT toutes les variables de l'entité à la fois et cette adresse /users/4/carPhoto
peut également être considérée comme une collection (le cas d'utilisation standard de l'API REST ressemble à ceci /users/4/shipments
). Habituellement, vous ne pouvez pas (et ne voulez pas) GET / PUT chaque variable d'entité, par exemple users / 4 / name. Vous pouvez obtenir le nom avec GET et le modifier avec PUT à users / 4. S'il y a quelque chose après l'identifiant, il s'agit généralement d'une autre collection, comme users / 4 / reviews
3. Utilisez Base64
Envoyez-le au format JSON mais encodez les fichiers avec Base64.
bon : Identique à la première solution, c'est le service le plus REST possible.
inconvénients : Une fois de plus, les tests et le débogage sont bien pires (le corps peut avoir des mégaoctets de données), il y a augmentation de la taille et aussi du temps de traitement à la fois - client et serveur
Je voudrais vraiment utiliser la solution no. 2, mais il a ses inconvénients ... N'importe qui peut me donner un meilleur aperçu de la solution "quelle est la meilleure"?
Mon objectif est d'avoir des services RESTful avec autant de standards inclus que possible, tout en souhaitant que les choses restent aussi simples que possible.