Использование параметров URL-запроса в POST

Question

Моя команда должна создать API для загрузки документов, например. PDF-файлы. Одна из моих целей - сделать это максимально безболезненным для вызывающих. Я считаю, что вызов POST с двоичным содержимым, предоставляемым как поток, является самым простым. Один из членов группы отметил, что необходимо предоставить метаданные вместе с этим документом. Его предположение, что для этого потребуется запрос с несколькими частями. На мой взгляд, это добавляет значительную сложность для пользователей сервиса.

Я предложил идею установки метаданных в строке запроса URL. Это позволяет использовать метаданные и простое решение потока для документа. Мы оба уверены, что это должно работать с технической точки зрения, но он чувствовал, что это нестандартное или потенциально не RESTful.

Это кажется довольно простым решением для меня, но я действительно не могу найти четкого ответа на вопрос, является ли это проблематичным. Я нашел несколько дискуссий, которые, кажется, об этом, но ответы, похоже, сводятся к «смешиванию GET и POST», которые я не соблюдаю вообще. Если я чего-то не упускаю, это не имеет никакого отношения к GET, просто POST и как структурируется URL-адрес для этого POST. Похоже, есть идея, что параметры запроса поддерживаются только GET, но я не думаю, что это так.

Может ли кто-нибудь предоставить авторитетную ссылку на это?

Answer 1

Это зависит от того, что вы подразумеваете под «проблематичным». Вероятно, нет ничего плохого в этом с точки зрения юзабилити. Помните, что REST - это архитектурный стиль , а авторитетные ссылки на стили могут быть такими же субъективными, как сами стили. Вы можете найти авторитетную ссылку на используемый вами протокол транспорта, HTTP, но когда это отклонение от протокола проблематично, а когда оно просто против пуризма? Прочтите RFC 7230 и 7231 и попытайтесь понять это.

Другими словами, я говорю, что если вы после авторитетного источника для урегулирования спора со своими коллегами, я не думаю, что вы его найдете.

Если вы просто хотите уточнить это, с точки зрения REST, URI являются атомарными идентификаторами ресурсов. Параметры запроса являются частью идентификатора, но поскольку они являются атомарными, их семантика не имеет значения. Это означает, что любая дискуссия о том, является ли URI RESTful или нет, бессмысленна. Пока URI указывает на один и только один ресурс, и он не получен из внеполосной информации, это RESTful, независимо от его содержимого. Конечно, вы должны попытаться иметь осмысленные и простые URI, которые легко понять, но это общий критерий для HTTP, а не ограничение REST.

Реальная проблема в вашем случае заключается в том, что семантика метода POST заключается в том, чтобы передать полезную нагрузку, подлежащую обработке ресурсом, идентифицированным URI, в соответствии с предопределенными правилами. URI, который вы используете в POST, не идентифицирует загружаемый файл, а ресурс, ответственный за загрузку. Если вы включаете метаданные для обработки в URI, вы фактически говорите, что каждый файл PDF загружается с другим ресурсом пользователя. С точки зрения REST нет ничего от этого неправильного, но это странно с точки зрения HTTP и удобства использования. Я ожидал, что один и тот же ресурс будет использоваться для всех, а также дополнительные данные, которые будут присутствовать в полезной нагрузке. В этом пункте я думаю, что ваш коллега прав, что вы должны использовать многосегментный запрос или формат мультимедийного типа, который позволяет вам упаковать файл PDF и метаданные вместе в полезной нагрузке.

Однако, если ваши метаданные не будут изменены после загрузки файла PDF - или, другими словами, если ваш URI не изменится - это отлично подходит для этого с помощью метода PUT. В отличие от метода POST, PUT не передает полезную нагрузку, подлежащую обработке ресурсом, идентифицированным URI, но просит сервер заменить ресурс в URI на тот, который содержится в полезной нагрузке.В этом случае URI действительно идентифицирует файл PDF, так что это нормально, если это не изменится.