API REST, когда ограничение GET сталкивается с семантикой

При создании API REST запрос данных должен выполняться с помощью запроса GET. Это учебник. Но GET ограничен диапазоном маленьких тысяч символов, тогда как POST не имеет такого ограничения (обычно несколько МБ).

Итак, как вы справляетесь с запросами, превышающими предел GET (подумайте, у вас есть API, и вы отправляете массив почтовых индексов, чтобы получить взамен массив имен)?

В этом конкретном случае я использую POST, поскольку массив превышает пределы GET. Это работает, но некоторым это покажется позорным. Так что мне интересно, какое правило решать такую ​​проблему. Запрашивать n раз уникальный почтовый индекс нельзя по очевидным причинам производительности.

Есть ли шаблоны на почтовом индексе? Не могли бы вы использовать диапазон? например code=AB-XY? Тогда общий консенсус для подобных сценариев состоит в том, чтобы просто использовать POST (несмотря на то, что это идет вразрез).

James 13.09.2018 00:04

Нет, предположим, что почтовые индексы являются случайными (это был только пример, это могут быть ценные бумаги, такие как ISIN капитала и т. д.).

comte 13.09.2018 16:15

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

James 13.09.2018 17:01
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
3
28
1

Ответы 1

REST - это просто обобщение Интернета, которым мы так часто пользуемся. Вы можете в основном применять те же методы в среде REST, что и в Интернете. Т.е. если имеется множество доступных опций или ввод произвольного текста, длина которого может превышать 2 тыс. символов, вы можете либо использовать POST для выполнения вызова и отправки данных через полезную нагрузку, либо изменить свой подход. В первом подходе отсутствует поддержка ценных свойств, таких как safe и idempotent, а также может вообще не быть кеширования.

Другой подход - смоделировать варианты, которые клиент может отправить как собственный ресурс. Это позволяет «именовать» определенные конфигурации, повторно использовать их и вызывать с помощью простого запроса GET. В HTML клиент может запросить все доступные конфигурации и выбрать ту, которая соответствует его потребностям, или запросить у сервера страницу формы для ввода вариантов и отправки их через POST на сервер. Эта конфигурация позже появится в будущих клиентских запросах доступных конфигураций.

Фактическая структура URI, указывающего на этот конкретный ресурс, обычно не имеет значения для клиента, поскольку для определения того, какой URI вызывать, следует использовать осмысленное (связующее) имя. Такие ресурсы можно легко вызвать через GET, который автоматически предоставляет вышеупомянутые свойства. Важнейшая часть здесь - найти схему именования, которая имеет смысл для клиентов, чтобы клиент понимал, для чего на самом деле подходит этот URI.

Кроме того, перевод формы в архитектуру REST может оказаться не самым тривиальным занятием. В HTML спецификация уже включает семантику для форм и вариантов выбора, а также для ссылок. Вы можете либо повторно использовать эту конкретную функцию, либо придумать свой собственный тип носителя, то есть application/vnd.form-hal+json, который может быть расширением HAL-JSON, который уже определяет структуру ссылок. Этот тип мультимедиа, в частности, сообщает получателю такой полезной нагрузки, что данные, полученные в таком представлении, предназначены для представления в формах или представляют данные формы и, следовательно, могут содержать ввод пользователя для отображения или сохранения.

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

Как вы, надеюсь, видите, тот же метод, который используется в Интернете, можно применить и к REST. Такой подход достаточно хорошо масштабируется и является дополнением к тому, что на практике довольно надежен, поскольку сервер учит клиента тому, как отправлять запросы, и клиенту не нужна какая-либо априорная информация об услуге. Этот метод также объясняет то, о чем просил Филдинг в одном из своих Сообщения в блоге:

A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

Другие вопросы по теме