Что такое хорошая практика RESTful для управления ресурсами в иерархии папок?

Question

Я - нуб REST, пытаюсь спроектировать мою первую схему REST API.

Рассмотрим простой REST API для перечисления / просмотра / редактирования / удаления пользовательских объектов. Мы могли бы использовать следующие 2 шаблона URL для маршрутизации:

/users          # GET returns a list of users, POST allows creation of new user
/users/{userid} # GET returns user info, PUT for updating user info, DELETE to delete user

Пока все хорошо. Теперь предположим, что пользователи могут быть расположены во вложенных папках. Таким образом, пользователь теперь может находиться внутри папки, а папка может содержать как пользователей, так и подпапки. Чтобы разрешить управление папками, мы хотим добавить следующие функции в наш API:

• Список содержимого (пользователи и подпапки) папки
• Создать новую папку
• Переименование, удаление папок
• Переместить пользователя или подпапку в другую родительскую папку

Каков наилучший способ предоставления этой функциональности в REST API? Я придумал две идеи:

Идея 1: Показать иерархию папок в URL

например. /users/folder1/folder2/chris

На первый взгляд это выглядит красиво, но с этим подходом есть ряд проблем:

• У пользователей и папок теперь один и тот же шаблон URL. Невозможно узнать, указывает ли /users/a/b/c на пользователя или папку. Это делает трудным для понимания API и раздражающей реализацией, включающей ручной анализ URL-адресов и догадки.

• Когда клиент отправляет POST на /users/folder1, мы не знаем, хотят ли они создать нового пользователя или новую подпапку. Их нужно будет указать в теле запроса. Опять же, это приводит к раздражающей реализации на стороне сервера и выглядит не очень RESTful.

• Нет очевидного способа разрешить перемещение ресурсов из одной папки в другую

Идея 2: Добавить информацию о родительской папке в ресурс

Сохраните простые шаблоны URL, показанные выше, и добавьте поле parentFolder к пользовательскому ресурсу.

например. GET до /users могут возвращаться (в JSON):

{'users': 
   [{'name':'chris','DoB':'1/1/1900','parentFolder':'/folder1/folder2'},
   ...]
}

Добавление отдельного шаблона URL /folders и /folders/{folderid} для просмотра / редактирования / удаления папок.

Это решает некоторые проблемы с Idea 1, но с точки зрения дизайна это делает меня неловким:

• Добавление родителя ресурса в качестве атрибута ресурса кажется странным.

• Почему мы должны разделять пользователей и их папки на отдельные API-интерфейсы, даже если они явно взаимосвязаны?

Спасибо, что прочитали это далеко. Есть ли лучший способ справиться с этим?

Answer 1

Нет ничего странного в добавлении ссылки на ваш пользовательский ресурс для идентификации содержащейся папки.RESTful дизайн - это 95% для добавления ссылок между ресурсами и 5% для определения того, как выглядит URI.

Выполнение POST для / users / a / b / c с пользовательским ресурсом или ресурсом папки должноне вызывает у вас беспокойства.Одним из основных преимуществ использования RESTful HTTP является то, что вы не ограничены пределами RPC.Мы привыкли к вызовам процедур, которые статически определяют, каковы входные параметры и выходные параметры.HTTP имеет поля заголовков, такие как Content-Type, которые позволяют определять входные и выходные параметры во время выполнения.

Я считаю, что вы правы, что вариант № 2, скорее всего, будет легче отправить на сервер, чем вариант № 1.Однако, пока вы избегаете создания URI на клиенте, используя сервер для возврата всех ссылок, которые могут понадобиться клиенту, любой из этих вариантов должен подойти для вашего клиента.

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

Answer 2

Я размышляю над тем же вопросом.

В настоящее время я склонен к http-ответу заголовки Content-Type application / octet-stream против application / json, чтобы уведомить клиента, если полезная нагрузка является ресурсом данных против ресурса папкии позволяют правильно интерпретировать полезную нагрузку.