REST - это обобщение Интернета, которым мы так часто пользуемся. В основном вы можете применять те же методы в среде REST, что и в Интернете. То есть Если имеется множество доступных опций или ввод свободного текста, который может легко превышать 2 тыс. символов, вы можете использовать POST для выполнения вызова и отправки данных через полезную нагрузку или изменить свой подход. В первом подходе отсутствует поддержка таких ценных свойств, как safe и idempotent, а также может вообще избежать кэширования.
Другим подходом было бы моделирование вариантов, которые клиент может отправить как собственный ресурс. Это позволяет определенным конфигурациям «именоваться» и повторно использоваться и вызываться с помощью простого запроса GET. В HTML клиент может запросить все доступные конфигурации и выбрать ту, которая соответствует его потребностям, или запросить у сервера страницу формы для ввода вариантов выбора и отправки их через POST на сервер. Эта конфигурация позже появится в будущих клиентских запросах на доступные конфигурации.
Фактическая структура URI, указывающая на этот конкретный ресурс, обычно не имеет значения для клиента, так как для определения того, какой URI вызывать, должно использоваться значимое имя (отношение ссылки). Такие ресурсы могут быть легко вызваны через GET, которые автоматически предоставляют вышеупомянутые свойства. Важнейшая часть здесь - найти схему именования, которая имеет смысл для клиентов, чтобы клиент понимал, для чего этот URI действительно полезен.
Также перевод формы в REST-архитектуру может быть не самым простым делом. В HTML спецификация уже включает семантику для форм и выборов, а также для ссылок. Вы можете либо повторно использовать эту конкретную функцию, либо придумать свой собственный медиа-тип, то есть application/vnd.form-hal+json, который может быть расширением HAL-JSON, который уже определяет структуру ссылок. Этот медиа-тип, в частности, сообщает получателю такой полезной нагрузки, что данные, полученные в таком представлении, предназначены для представления в формах или представляют данные формы и, следовательно, могут содержать пользовательский ввод для отображения или сохранения.
Клиент, который не находит подходящей конфигурации текущих запросов, может поэтому спросить у сервера, как создать новую конфигурацию. Сервер проинформирует клиента с полезной нагрузкой вышеупомянутого представления, которое, если оно понято клиентом, приведет к тому, что клиент либо будет показывать данные осмысленно своему пользователю, либо даже позволит клиенту принять это представление и заполнить требуемое информация сама по себе и отправить ее через POST обратно на сервер для создания новой конфигурации запроса. Дальнейший запрос доступных конфигураций должен также перечислить новую.
Как вы, наверное, видите, тот же метод, который используется в Интернете, может быть применен и к REST. Такой подход довольно хорошо масштабируется и является дополнением к этому достаточно надежному на практике, поскольку сервер учит клиента тому, как отправлять запросы, и клиент не нуждается в априорной информации об услуге. Эта техника также объясняет то, о чем Филдинг просил в одном из своих сообщений в блоге :
API REST должен потратить почти все свои описательные усилия на определение типов носителей, используемых для представления ресурсов и управления состоянием приложения, или на определение имен расширенных отношений и / или разметки с поддержкой гипертекста для существующие стандартные типы мультимедиа. Любые усилия, затрачиваемые на описание методов, которые следует использовать с интересующими URI, должны быть полностью определены в рамках правил обработки для типа мультимедиа (и, в большинстве случаев, уже определены существующими типами мультимедиа). , [ Ошибка здесь означает, что внешняя информация является движущей силой взаимодействия, а не гипертекста. ]