Czy interfejs API RESTful może zwracać pliki lub tylko lokalizację

12

Zastanawia mnie to od dłuższego czasu.

Na przykład mamy interfejs API REST, który zapewnia podstawową zawartość systemu, zużywając i produkując JSON. W tym punkcie końcowym generuje adres URL obrazu i opisu, i można go znaleźć tak: // localhost / myApi / pictures / 1

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

Teraz OUR_URL powinien wskazywać lokalizację w interfejsie API, na przykład // localhost / myApi / files / pictures / 1, która zwraca JPG (aplikacja za API odczytuje fizyczną zawartość pliku, a następnie przesyła strumieniowo z powrotem do klienta ). To oczywiście różni się od reszty interfejsu API, który generuje odpowiedzi JSON, i będzie istniał narzut związany z odczytywaniem i przesyłaniem strumieniowym rzeczywistego pliku.

Ewentualnie OUR_URL powinien wskazywać adres URL spoza zakresu usługi REST, więc //localhost/files/pictures/1.jpg, gdzie bezpośrednio odczytuje plik.

Pytanie brzmi:

Czy interfejs API RESTful powinien być w stanie zwracać pliki, czy tylko lokalizację?

rest patterns-and-practices Szalony Dino
źródło
1
Zdajesz sobie sprawę, że ogólny opis tego, czym jest REST, to „klienci wysyłają żądania do adresu URL, a serwer zwraca rzeczy”, prawda? Cały pomysł polega na tym, że REST jest bardzo luźno zdefiniowany i można go dostosować do prawie każdego schematu pobierania opartego na adresach URL.

Odpowiedzi:

17

Usługa RESTful powinna zapewniać zasoby użytkownikom interfejsu API. Zasoby mogą mieć różne formaty, od JSON lub XML do JPEG i HTML.

Nie ma nawet wymogu ani nawet oczekiwań, że pojedynczy interfejs API obsługuje tylko zasoby jednego formatu. Nie ma nic złego w podawaniu dokumentu JSON w URI /myApi/pictures/1i pliku JPEG z URI /myApi/files/pictures/1.
W bardziej ekstremalnym przypadku możliwe jest nawet podanie zarówno opisu JSON, jak i pliku JPEG z tego samego adresu URL, w zależności od formatu, o który prosi requester.

Bart van Ingen Schenau
źródło
7

Jednym z problemów, które będziesz mieć podczas zwracania identyfikatorów URI, jest to, że zwykły stary serwer plików nie może zapewnić bezpieczeństwa. Jeśli więc musisz ograniczyć liczbę osób, które mogą uzyskać dostęp do pliku, będziesz musiał móc zwrócić go bezpośrednio w interfejsie API REST (lub nie, jeśli użytkownik nie ma uprawnień, plik jest nieprawidłowy stan itp.).

W przeciwnym razie zwrócenie zwykłego starego identyfikatora URI i pozostawienie go w dedykowanym CDN ma wiele zalet związanych z obsługą administracyjną, prostotą i skalowalnością - przy założeniu, że to wszystko, co musisz zrobić.

Telastyn
źródło
Aspekt autorski to bardzo dobra kwestia, coś, czego nigdy nie rozważałem.
Szalony Dino