Существуют ли какие-либо стандартные методы проектирования для архитектур RESTful?

Одним из недостатков самообучения является то, что вы навсегда изобретаете колесо.

Я все больше работаю над архитектурой RESTful и, как результат, должен определить ресурсы и как можно взаимодействовать с ними.

Существуют ли стандартные (и эффективные) методы или шаблоны проектирования, которые помогают перечислять различные HTTP-глаголы и потенциальные ответы для ресурсов, чтобы гарантировать, что все перестановки будут покрыты?

Даже что-то основное:

+----------------+---------------------------------------------+
| Resource Name: |                                             |
+----------------+---------------------------------------------+
|                      HTTP METHODS                            |
+------------+-------------------------------------------------+
| Method     |  Supported                                      |
+------------+-------------------------------------------------+
| GET        |     X                                           |
| PUT        |     X                                           |
| POST       |                                                 |
| DELETE     |                                                 |
+------------+-------------------------------------------------+
|                        RESPONSES                             |
+--------------------------------------------------------------+
| GET                                                          |
+--------------------------------------------------------------+
| Details of valid and necessary parameters for GETs and the   |
| possible responses...                                        |
| ...                                                          |
+--------------------------------------------------------------+

Конечно... Я мог бы опрокинуть свои собственные, но задаюсь вопросом, есть ли там широко известные методологии, которые я мог бы принять.

Ответ 1

Поскольку я опубликовал это, я недавно обнаружил ряд дизайнеров API. Один из них (Mulesoft Anypoint Platform) использует язык под названием RAML (язык моделирования RESTful API).

Ответ 2

Возможно, вам стоит взглянуть на Язык описания веб-приложений. Некоторые структуры REST могут даже генерировать описание для вас. Мне нравится Apache Jersey (если вы можете принять Java для реализации).

Ответ 3

RestMS.org содержит стандарт для разработки Restful API.

Это не следует рассматривать как евангелие, но вы узнаете многое, прочитав определение одной страницы RestTL (Restful Transport Layer).

http://www.restms.org/spec:1

Ответ 4

Самый распространенный и понятный метод - сделать ваши сообщения RESTful самоописательными:

GET /foo HTTP/1.1

HTTP/1.1 200 OK
Allow: GET, PUT
...

{"description": "A foo. PUT a new representation to overwrite this one.", ...}

/foo - это "Имя ресурса", заголовок "Разрешить" - это список "МЕТОДОВ HTTP", а тело ответа определяет информацию "RESPONSES" как в прозе, так и в виде набора элементов управления (например, HTML).

Чтобы обеспечить защиту всех перестановок, пишите тесты.

Ответ 5

Нет стандартных методов для разработки API REST, насколько я знаю. И люди часто проводят слишком много времени, обсуждая, должны ли они использовать PUT или POST для определенного метода. Я считаю, что самое главное - сохранить его просто, быть в соответствии с использованием глаголов и форматов и очень хорошо документировать его.

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

Если вы ищете шаблон, ознакомьтесь с рекомендациями API REST от Atlassian. По моему опыту, wiki работает намного лучше, чем любой инструмент, который автоматически генерирует документацию из кода.

Ответ 6

Нет стандартного способа описания дизайна RESTful Application/API, поскольку REST является архитектурным принципом +, а не четко определенной структурой или шаблоном проектирования.

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

Ресурсы, которые ваше приложение будет предоставлять
Способы, которые будут принимать каждый ресурс
Связи между каждым ресурсом

С этого момента вы сможете создать внутреннюю схему URL вашего приложения, создать общедоступный URL и т.д.