Понимание REST на примере

Question

Мое единственное реальное знакомство с идеями REST было через Ruby on Rails RESTful маршрутизация . Это хорошо мне подходит для приложений на основе CRUD, которые я создал с помощью Rails, но, следовательно, мое понимание RESTfulness несколько ограничено.

---

Допустим, у нас есть конечная коллекция Предметов, каждый из которых имеет уникальный идентификатор и ряд свойств, таких как цвет, форма и размер (которые могут быть неопределенными для некоторых Предметов).

Элементы могут использоваться клиентом в течение определенного периода времени, но каждый элемент может использоваться только одним клиентом одновременно. Доступ к Предметам регулируется сервером. Клиенты могут запросить временное использование определенных элементов с сервера.

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

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

Клиент может сделать следующие виды запросов:

• Скажите, сколько есть предметов зеленого треугольника (всего / доступно).
• Дайте мне использовать 200 больших красных предметов.
• Я закончил с пунктами 21, 23, 23.
• Добавьте 100 новых предметов красного квадрата.
• Удалить 50 маленьких зеленых предметов.
• Измените все большие желтые элементы пятиугольника на синий.

---

Приведенный выше пример с игрушкой напоминает проблему распределения ресурсов, с которой мне недавно пришлось столкнуться. Как мне думать об этом с удовольствием?

Answer 1

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

В остальном мире все глаголы «предустановлены», и существительные становятся бесконечно гибкими. В мире мыла или Рока глаголы бесконечно гибки. Ограничьте свое мышление блокировкой глаголов, а затем посмотрите, какие существительные вам нужны для решения вашей проблемы в рамках имеющихся у вас ограничений.

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

Некоторые из ваших вопросов были связаны с поиском или фильтрами - для тех, кто думает о GET для типов ресурсов, передавая параметры запроса для ограничения или фильтрации результатов.

Answer 2

Если блокировка ресурсов действительно является проблемой домена в вашем сценарии, то я бы рекомендовал моделировать блокировку как ресурс.

Вот несколько советов о том, как вы могли бы выполнять предложенные вами запросы.

GET /Triangle/Green/Count
GET /Triangle/Green/Available

POST /Item/Red/Large/Locks?quantity=200

DELETE /Item/21/Lock
DELETE /Item/23/Lock
DELETE /Item/25/Lock

POST /Square/Red?quantity=100

DELETE /Item/Green/Small?quantity=100

POST /Pentagon/Blue?url=/Pentagon/Yellow

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

Answer 3

Прочтите это для базовых знаний ... Я застрял в том, что такое ОТДЫХ ... !!!

Система управления контентом может содержать ряд статей.Здесь подразумевается два ресурса.Во-первых, есть отдельные статьи.Каждый составляет ресурс.Есть также второй ресурс: коллекция статей.

Чтобы получить список всех статей, мы могли бы выполнить HTTP-запрос GET для этой коллекции, скажем, по пути / статьям.Чтобы получить содержимое отдельного ресурса, мы должны его идентифицировать.Способ Rails состоит в том, чтобы дать значение его первичного ключа (то есть его идентификатор).Опять же, мы выпустим запрос GET, на этот раз по URL / article / 1.Пока что все это выглядит довольно знакомо.Но что происходит, когда мы хотим добавить статью в нашу коллекцию?

В приложениях, не относящихся к RESTful, мы, вероятно, изобрели бы какое-нибудь действие с глагольной фразой в качестве имени: article / add_article / 1.В мире REST мы не должны этого делать: мы должны сообщать ресурсам, что делать, используя стандартный набор глаголов.Чтобы создать новую статью в нашей коллекции с использованием REST, мы бы использовали HTTP-запрос POST, направленный на путь / article, с данными публикации, содержащей статью, которую нужно добавить.Да, это тот же путь, который мы использовали для получения списка статей: если вы даете ему GET, он отвечает списком, а если вы делаете POST, он добавляет новую статью в коллекцию.

Сделай шаг вперед.Мы уже видели, что вы можете получить содержимое статьи, выполнить запрос GET по пути / article / 1.Чтобы обновить эту статью, вы должны выполнить HTTP-запрос PUT для того же URL-адреса.И, чтобы удалить его, вы можете выполнить запрос HTTP DELETE, снова используя тот же URL.