Interfejs API do przesyłania plików: Multipart/form-data vs. surowa zawartość w treści?

Question

Zauważyłem, że istnieją (przynajmniej) dwa sposoby przesyłania pliku na serwer HTTP za pośrednictwem interfejsu API.

Możesz użyć multipart/form-data (czyli tego, co przeglądarki robią natywnie dla plików HTML do przesyłania plików), ale możesz także POST zawartość pliku wewnątrz treści żądania (być może z poprawnym nagłówkiem żądania Content-Type).

Jakie są plusy i minusy każdej metody (w ogóle, nie od przeglądarki)?

Żądania wieloczęściowe na przykład - w zależności od używanej biblioteki http lub sieciowej używanej w środowisku programistycznym (używam Node.js po stronie serwera i Swift po stronie klienta) - wydaje się nieco bardziej skomplikowane tworzenie i następnie przeanalizuj.

Answer 1

Jedyną różnicą na poziomie protokołu jest to, że żądania multipart/form-data muszą być zgodne z RFC 2388, podczas gdy niestandardowa treść żądania może być dowolna.

Praktyczny wniosek z tego jest taki, że żądanie multipart/form-data jest zwykle większe: podczas gdy klienci są technicznie uprawnieni do używania non-7bit content-transfer-encoding, base64 jest używany przez większość. Nagłówki MIME generują dodatkowe obciążenie, które może stać się wąskim gardłem, jeśli załaduje się wiele małych plików. Należy zauważyć, że obsługa przesyłania plików w istniejących klientach/bibliotekach jest znacznie bardziej rozpowszechniona. Powinieneś zawsze podawać go jako rezerwowy, jeśli nie masz wystarczającej pewności co do zestawu funkcji swoich klientów i pośrednich hostów (serwerów proxy). Szczególnie należy pamiętać, że jeśli projektujesz API dla stron trzecich, inni programiści będą już zaznajomieni z multipart/form-data i będą mieli do dyspozycji biblioteki do pracy.