Si une API RESTful est capable de renvoyer des fichiers ou simplement un emplacement

12

Cela me laisse perplexe depuis un moment.

Par exemple, nous avons une API REST qui fournit un contenu de base à un système, consommant et produisant du JSON. À ce point final, il produit une URL vers une image et une description, et se trouve comme ceci: // localhost / myApi / pictures / 1

{
    id: 1,
    description: "This is a pretty picture of a daisy",
    URL: <OUR URL>
}

Maintenant, l'URL_URL doit pointer vers un emplacement sur l'API, par exemple // localhost / myApi / files / pictures / 1 qui renvoie un JPG (l'application derrière l'API lit le contenu physique du fichier, puis le retransmet au client ). Ceci est évidemment différent du reste de l'API qui produit des réponses JSON et il y aura des frais généraux de la lecture et du streaming du fichier réel.

Sinon, OUR_URL doit pointer vers une URL en dehors de la portée du service REST, donc //localhost/files/pictures/1.jpg où il lit le fichier directement.

La question est donc:

Une API RESTful doit-elle être capable de renvoyer des fichiers ou simplement un emplacement?

rest patterns-and-practices

— Crazy Dino
source

1

Vous vous rendez compte que la description générale de ce qu'est REST équivaut à «les clients font des demandes à une URL et le serveur renvoie des trucs», non? L'idée générale est que REST est défini de façon très lâche et peut être adapté à presque tous les schémas de récupération basés sur des URL.

17

Un service RESTful doit fournir des ressources aux utilisateurs de l'API. Les ressources peuvent avoir différents formats, qui vont de JSON ou XML à JPEG et HTML.

Il n'y a même pas d'exigence, ni même d'attente, qu'une seule API ne serve que des ressources d'un seul format. Il n'y a rien de mal à servir un document JSON sur l'URI /myApi/pictures/1et un fichier JPEG de l'URI /myApi/files/pictures/1.
Dans un cas plus extrême, il est même possible de servir à la fois la description JSON et le fichier JPEG à partir de la même URL, selon le format demandé par le demandeur.

— Bart van Ingen Schenau
source

7

Un problème que vous rencontrerez en renvoyant simplement des URI est qu'un ancien serveur de fichiers ordinaire ne peut pas assurer la sécurité. Donc, si vous avez besoin de restreindre l'accès à un fichier, vous devrez pouvoir le renvoyer directement dans l'API REST (ou non, si l'utilisateur n'a pas de droits, le fichier est pas dans le bon état, etc.).

Sinon, le retour de l'ancien URI et le transfert à un CDN dédié présente de nombreux avantages en termes de provisionnement, de simplicité et d'évolutivité - en supposant que c'est tout ce que vous devez faire.

— Telastyn
source

L'aspect auth est un très bon point, quelque chose que je n'avais jamais considéré.

— Crazy Dino