Основной вопрос в моей голове остается: зачем вам это нужно?
На мой взгляд, с точки зрения REST это звучит как анти-паттерн.REST - это обобщение веб-ориентации с возможностью просмотра на компьютерах, а не на людях, хотя те же концепции, которые применяются к сети, в основном применимы и к приложениям, которые следуют архитектуре REST.
Множество сервисов CRUD позволяют создавать новые ресурсы с помощью POST запросов.Здесь семантика полезной нагрузки определяется сервером.Клиенту либо нужна внеполосная информация о том, как создать такую полезную нагрузку, либо сервер должен каким-то образом обучать клиента такой информации.В Интернете это делается с помощью форм.Форма определяет не только необходимый ввод данных, но и куда отправлять полезные данные.То же самое можно сделать в приложениях, соответствующих архитектурному стилю REST.Здесь форма должна быть описана как собственный медиа-тип, который используют и понимают и сервер, и клиенты, подобно HTML, который сервер и браузеры знают и понимают.В отсутствие выделенного медиа-типа, представляющего форму, которую можно использовать в архитектуре REST, можно просто повторно использовать возможности формы HTML, т. Е.
. Получение данных с сервера также должно исключать интерпретацию ресурса определенного ресурса.тип.Это легко может обмануть вас в набранной ловушке ресурса .Вместо этого следует использовать content-type negotiation, когда клиент сообщает серверу о своих возможностях, а сервер пытается ответить представлением, которое клиент может использовать.Что касается вышеупомянутого примера формы, клиент и сервер могут договориться о чем-то вроде application/form+json представления, где сервер в основном возвращает информацию, аналогичную HTML-формам, только в синтаксисе JSON.Однако следует позаботиться о пользовательских типах носителей.Они должны быть как можно более универсальными, чтобы их можно было применять ко многим клиентам, иначе высоки шансы, что поддержка таких типов носителей будет весьма ограниченной.
Вместе с HATEOAS, который в основном добавляет поддержку link-имена отношений и избегает синтаксического анализа и интерпретации URI, но использует их только для вызова следующей операции на целевой конечной точке; это фундаментальные предварительные условия IMO, которые архитектура REST накладывает как на клиентов, так и на серверы, чтобы получить высокую степень развязки,свобода на стороне сервера развиваться без страха ломать клиентов и повышать их готовность к изменениям.
При применении этих шагов ресурс становится в значительной степени самоописанным.Нет реальной необходимости во внешней документации или другой внеполосной информации, если все сделано правильно, или в том, что клиентские классы-заглушки / скелетоны взаимодействуют с API, поскольку в конечном итоге URI и HTTP являются необходимыми интерфейсами, которые должны поддерживать клиенты.
Если вам требуется поддержка пользовательских заголовков, сервер должен сообщить клиенту об отсутствии тех, которые его ожидают.Это похоже на базовую аутентификацию.Клиент отправляет запрос на сервер, и сервер отвечает 401 Unauthorized ответом, содержащим заголовок, такой как WWW-Authenticate: Basic realm="fooBar", который сообщает клиенту, что сервер ожидает базовую аутентификацию с упомянутой областью.Многие клиентские реализации знают, что пользователь и пароль / ключ требуются в форме, подобной username:password, которую необходимо кодировать base64 и добавлять к строке Basic.Обычно это делается сзади без особого вклада с вашей стороны.Однако для настраиваемого заголовка это может быть не так просто автоматизировать.Но вы все равно можете выдавать соответствующие коды ошибок, такие как 409 Conflict или 422 Unprocessable Entity, чтобы информировать клиента о необходимом, но отсутствующем заголовке.Такие пользовательские заголовки лучше всего описаны в медиа-типах, хотя они включают как синтаксическое, так и семантическое описание обмениваемых представлений, включая необязательные заголовки.
Если вам нужно сгенерировать такие свойства для генерации кода-заглушки или конфигурации клиента, вы, скорее всего, будете иметь не REST, а скорее RPC-подобную систему, специально предназначенную для взаимодействия с вашим API, но не работающую налюбая другая конечная точка.Такой код на стороне клиента может, в зависимости от его внутренних компонентов, легко сломаться, хотя, если вы измените, например, свою структуру URI или что-то в обмененном формате сообщения.Это также очень похоже на генерацию клиентского заглушки SOAP / WSDL, где можно получить представление службы WSDL в формате XML, сгенерировать некоторые классы заглушек и затем реализовать их на этих интерфейсах.Проблема обычно заключалась в том, что если что-то было изменено в файле WSDL после того, как был создан код заглушки клиента, клиентам необходимо было обновить классы заглушки и в конечном итоге обновить свой код клиента для взаимодействия с созданными интерфейсами.Это особенно обременительно, если единственный канал, с которого вы получаете информацию об обновлениях, это тот канал, который вы не часто посещаете (то есть домашняя страница сопровождающих).В большинстве случаев вы наблюдаете проблему только тогда, когда сервис уже обновлен.Это случилось с нами пару лет назад, пару раз назад, что вынудило нас выпустить некоторые обновления для приложений, развернутых на различных клиентских машинах, что стоило нам пару человеко-дней на их обновление.
Я надеюсь,Вы можете понять, почему я рассматриваю это как шаблон с точки зрения REST, когда сервер должен информировать клиента обо всем, что ему нужно для дальнейших действий, или предоставить клиенту способ предоставить недостающую информацию и отправить ее на сервер..