Откуда вы знаете формат для отправки данных в API на основе отдыха, если нет документации?
Сервер должен научить клиента, как должен выглядеть запрос.В HTML, т. Е. Это делается через веб-форму, которая включает все элементы, которые поддерживает сервер.В случае обновления поля могут быть автоматически заполнены текущими значениями, которые могут быть изменены пользователем / приложением.Поскольку форма также содержит URI для отправки данных, клиент может просто инициировать запрос, вызвав кнопку отправки формы.
Для API REST подобный подход может и должен быть применен.Здесь сервер может дать клиенту подсказку о поддерживаемых типах мультимедиа (в зависимости от того, поддерживает ли тип мультимедиа, полученный клиентом, такую функцию), что также можно найти с помощью операции OPTIONS, которая информирует клиента овозможности конечной точки, такие как поддерживаемые типы медиа или операции, которые могут быть вызваны на конечной точке.
Должен ли метод get для коллекции возвращать пример элемента?
Если клиенту предоставляется форма, которая объясняет, как должен выглядеть запрос, здесь не требуется никакой внеполосной информации, так что в этом нет необходимости.
Как вы связалисьМодель зрелости Ричардсена (RMM): ИМО, эта модель не имеет особого смысла с точки зрения REST.Во-первых, в любом случае не существует приверженности REST до уровня 3, и даже при наличии уровня 3 у вас нет гарантии того, что вы действительно соответствуете архитектуре REST.
Это, вероятно, требует дополнительного объяснения, я полагаю.REST - это модель взаимодействия, а не протокол.Он использует свойства, которые сделали Интернет столь успешным, как, например, простое масштабирование посредством связи без сохранения состояния и снижение рабочей нагрузки за счет кэширования ответов на промежуточных серверах или распределения запросов между серверами с балансировкой нагрузки.Одна из его целей - разделение клиентов и серверов, позволяя последнему свободно развиваться, не опасаясь взлома первых.Таким образом, сервер должен обучить клиента всему, что ему нужно, чтобы сделать осознанный выбор, какие «действия» выполнять дальше.
Т.е. сервер предоставит все ссылки, которые могут понадобиться клиенту, включая некоторое сопутствующее отношение ссылок.имена, где имена отношений дают URI именованный контекст, который клиент может использовать, чтобы решить, вызывать его или нет.Такие имена либо стандартизированы с помощью IANA , либо должны быть абсолютными URI, как определено в RFC 8288 - Web Linking , то есть как Dublin Core расширения.Эта концепция позволяет серверу в любое время изменять URI ресурсов.Клиенты, уважающие эту концепцию, по-прежнему смогут обрабатывать свои задачи, в то время как клиенты, анализирующие и анализирующие такие URI, могут в результате этого сломаться.
Согласно Fielding
API REST должен тратить почти всеего описательных усилий в определении типа (типов) мультимедиа, используемых для представления ресурсов и управления состоянием приложения, или в определении имен расширенных отношений и / или разметки с поддержкой гипертекста для существующих стандартных типов мультимедиа.Любое усилие, затрачиваемое на описание того, какие методы использовать с какими интересующими URI, должно быть полностью определено в рамках правил обработки для типа носителя (и, в большинстве случаев, уже определенных существующими типами носителя) ( Источник )
В дополнение к этому Филдинг упомянул, что клиенты не должны относиться к ресурсам определенного типа , а вместо этого договариваются с сервером о поддерживаемых форматах представления, понятных обоим приложениям, через согласование типа контента. У клиента, который ожидает, что конечная точка http://acmee.com/api/users вернет представление JSON с предопределенными полями, могут возникнуть определенные проблемы, если ответ поставляется с другими именами полей или с другими типами значений или в целом с другой структурой, отличной от ожидаемой. Это также напрямую связывает клиента с возвращаемым значением определенного API и, таким образом, требует определенных внеполосных знаний. Это то, чего не хватает в RMM. Следовательно, даже если вы достигли уровня 3 в RMM, вы все равно можете не соблюдать все ограничения, которые Fielding накладывает, чтобы придерживаться стиля архитектуры REST.