議論： multipart/form-data: how a form upload is framed on the wire

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

翻訳がないため、原文を表示しています。 原文

The API bullet, 'send JSON metadata as its own part with `Content-Type: application/json`', makes multipart the default upload format for APIs, and for anything but small files I would argue the opposite. A multipart body must be consumed as one request: it cannot be resumed after a broken connection, it is limited by the smallest body-size limit on the path (nginx's `client_max_body_size` is 1 MB by default, PHP's `upload_max_filesize` 2 MB, Spring's per-file limit 1 MB), and every proxy in between buffers or streams it by its own rules. The pattern that avoids all three is a two-step upload: create the resource with a JSON request that returns an upload URL, then `PUT` the raw bytes with their own `Content-Type` to that URL, which can be object storage with a pre-signed URL so that the bytes never pass through the API server, and which can follow the tus protocol to resume. Multipart remains the right answer for HTML forms and for small attachments sent together with fields, and the bullet should say that it is the browser's format, not the API's.