Переменная полезная нагрузка в POST

Question

Это больше вопрос дизайна.Допустим, у меня есть конечная точка для создания дома.У каждого дома есть адрес и другие характеристики.Давайте сейчас сосредоточимся на адресе.

Представляем унаследованный мир, в котором мы можем публиковать в / home полезную нагрузку, содержащую address_id, который является ссылкой на внешнюю систему с проверкой адреса и т. Д.

Теперь мы хотели бы поддержать создание адреса (во внешней системе), чтобы упростить количество звонков, которые должны делать наши клиенты.Клиент может / может просто позвонить нам, чтобы создать дом с указанным значением адреса, а не 2 вызовами.

Введите POST для / home с указанным либо address_id, либо строкой address_value (но не оба).Это заставит наш сервер заглянуть внутрь полезной нагрузки и решить, нужно ли ему вызывать внешнюю адресную систему от имени клиента, в зависимости от того, какое поле (address_id vs address_value) представлено в полезной нагрузке POST.

Вопрос:Поведение переменной, основанное на полях в запросе, похоже на анти-шаблон.Это также похоже на тесную связь между устаревшим полем и новым полем, которое мы пытаемся поддерживать.

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

Есть ли другие варианты дизайна?

Answer 1

Переменное поведение, основанное на полях в запросе, выглядит как анти-шаблон.

Это, вероятно, менее анти-шаблон, чем кажется.

Исторически SOAP, а в последнее время и GraphQL, во многом были «POST полезной нагрузкой на ресурс, и мы выясним это с другой стороны».

HTTP - это протокол приложения, домен приложения которогопередача документов по сети.- Джим Уэббер, 2011

REST ограничивает нас в использовании ограниченного набора сообщений - «пять глаголов и истина» - так что неизбежно будет некоторое удвоениегде-то.

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

Итак, в HTML у нас может быть много разных форм, которые все POST к одному ресурсу, потому чтоуспешная обработка этих форм делает недействительными кэшированные представления этого ресурса.

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

Это не значит, что вы не можете использовать более мелкозернистые ресурсы - это тоже нормально.Но они «должны» быть ресурсами, которые имеют свои собственные представления, а не просто конечными точками RPC с различным написанием для каждой «ответственности».