REST API дизайн - PullRequest
Новая
       11

REST API дизайн

2 голосов
/ 13 января 2012

Я пишу REST API и хочу получить отзывы. У меня будет один ресурс под названием Предметы. Я хочу, чтобы к нему обращались публично, или он может быть приватизирован (это может видеть только пользователь). Моя первая идея заключалась в том, чтобы поместить URL-адрес в общедоступные элементы, такие как / Root / Элементы, где будут находиться открытые элементы, и другие URL-адреса, такие как / Root / User / Items, где будут находиться частные элементы. Элемент может быть связан с другим пользователем, поэтому у него будет разрешение на его обновление. Что-то вроде / Root / User / Operator / Items .... но потом я понимаю, что создаю слишком много адресов.

Мне не нравится идея помещать все элементы в URL de / Root / Items, потому что у каждого пользователя будет свой вывод. И если поместить его только в / Root / user / Items, список всех открытых элементов (которые могут принадлежать любому пользователю) будет невозможен.

Есть идеи, как мне это сделать?

1 Ответ

0 голосов
/ 18 января 2012

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

Моя первая идея заключалась в том, чтобы поместить URL-адрес для общедоступных элементов, таких как / Root / Items, где будут находиться общедоступные элементы, и другого URL-адреса, например / Root/ Пользователь / Предметы, где будут жить личные предметы.

Я предполагаю, что вы говорите не только о ресурсах коллекции, которые будут возвращать коллекцию элементов.Я предполагаю, что у вас также будут отдельные ресурсы.URI одного элемента может быть / Root / Items / 42 или / Root / User / Items / 23 в вашей схеме.

Вы можете использовать различные схемы URI для открытых и закрытых элементов, если это поможет вам выполнитьавторизация нужна.Но в любом случае URI не имели значения в REST.URI должны всегда считаться непрозрачными.Если вы используете эти разные схемы для общедоступных и личных предметов, вы должны убедиться, что публичный предмет никогда не станет частным, и наоборот.В этом случае URI элемента изменится, и это будет так же, как если бы вы изменили первичный ключ строки в базе данных.Идентификаторы не должны меняться.То, что вы делаете, если вы используете разные схемы URI для открытых и закрытых элементов, - это кодирование уровня конфиденциальности ваших элементов в идентификаторы.Если ваш проблемный домен разрешает это, это нормально.

Элемент может быть связан с другим пользователем, поэтому у него будет разрешение на его обновление.Что-то вроде / Root / User / Operator / Items .... но потом я понимаю, что создаю слишком много адресов.

Это звучит так, как будто вы хотите изменить уровень конфиденциальности элемента.Как я уже говорил, у одного элемента должен быть ровно один URI, который никогда не меняется.Если вы говорите о ресурсах сбора, ваша схема может быть.Я не уверен, что вы имеете в виду здесь.

В конце: вам нужны аутентификация и авторизация.Вам нужно вернуть 403 Запрещено, если пользователь хочет получить доступ к личному элементу другого пользователя независимо от его URI.

...