Azure Blob Storage pour héberger des images / médias - récupération avec l'URL du blob (sans contrôleur intermédiaire)

Question

En este l'auteur propose une méthode de téléchargement via un contrôleur WebAPI. Cela me semble logique.

Il recommande ensuite d'utiliser un contrôleur d'API et une méthode de service dédiée pour fournir le blob :

 public async Task<HttpResponseMessage> GetBlobDownload(int blobId)
 {
    // IMPORTANT: This must return HttpResponseMessage instead of IHttpActionResult

    try
    {
        var result = await _service.DownloadBlob(blobId);
        if (result == null)
        {
            return new HttpResponseMessage(HttpStatusCode.NotFound);
        }

        // Reset the stream position; otherwise, download will not work
        result.BlobStream.Position = 0;

        // Create response message with blob stream as its content
        var message = new HttpResponseMessage(HttpStatusCode.OK)
        {
            Content = new StreamContent(result.BlobStream)
        };

        // Set content headers
        message.Content.Headers.ContentLength = result.BlobLength;
        message.Content.Headers.ContentType = new MediaTypeHeaderValue(result.BlobContentType);
        message.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("attachment")
        {
            FileName = HttpUtility.UrlDecode(result.BlobFileName),
            Size = result.BlobLength
        };

        return message;
    }
    catch (Exception ex)
    {
        return new HttpResponseMessage
        {
            StatusCode = HttpStatusCode.InternalServerError,
            Content = new StringContent(ex.Message)
        };
    }
 }

Ma question est la suivante : pourquoi ne pouvons-nous pas simplement référencer l'URL du blob directement après l'avoir stocké dans la base de données (au lieu de le récupérer via l'ID du blob) ?

Quel est l'avantage de récupérer les données à travers un contrôleur comme celui-ci ?

Answer 1

Vous pouvez certainement livrer un blob directement, ce qui évite alors d'utiliser les ressources de votre niveau d'application (vm, service d'application, etc.). Notez simplement que, si les blobs sont privés, vous devrez fournir une URI spéciale signée à l'application cliente (par exemple, en ajoutant une signature d'accès partagé) pour permettre l'utilisation publique de cette URI (pour une période temporaire). Vous généreriez le SAS dans votre tier d'application.

Toute la logique de contrôle d'accès reste dans le contrôleur, pour décider qui a les droits sur l'objet, pour combien de temps, etc. Mais vous n'auriez plus besoin de diffuser le contenu dans votre application (ce qui consomme du processeur, de la mémoire et des ressources réseau). Et vous pourrez toujours utiliser https avec un accès direct au stockage.

Answer 2

Tout simplement, vous pouvez appliquer le contrôle d'accès de manière centralisée lorsque vous utilisez un contrôleur. Vous avez beaucoup plus de contrôle sur qui/quoi/pourquoi accède au fichier. Vous pouvez également consigner les demandes assez facilement.

À plus long terme, vous voudrez peut-être changer l'emplacement de vos fichiers, ajouter une stratégie de partitionnement pour l'évolutivité, ou faire quelque chose d'autre dans votre application qui nécessite un changement que vous ne voyez pas pour le moment. Lorsque vous utilisez un contrôleur, vous pouvez isoler le code client de tous ces changements inévitables.