Использование интерфейса REST для нескольких ресурсов

Question

В настоящее время я добавляю REST API через http в онлайн-сервис и столкнулся с очень простой проблемой, для которой не могу найти ответ, который меня устраивает:

У меня есть в основном 2 ресурса: «пользователь» и «отчеты», как вы, наверное, догадались, отчеты связаны с пользователями (одному и только одному, = внешний ключ в моей базе данных)

В любом случае, у меня есть это отображение URL для GET:

• mywebsite/api/users/{id}: возвращает пользователя и связанную с ним информацию или список пользователей, если идентификатор отсутствует
• mywebsite/api/report/{id}: возвращает отчет и связанную с ним информацию или список отчетов, если идентификатор отсутствует

Теперь я хотел бы получить отчеты для конкретного пользователя, мой способ сделать это сейчас - добавить необязательный параметр в метод GET для отчетов: ?username={username} и, если он присутствует, я фильтрую результаты, чтобы вернуть только отчеты для этого пользователя.

Я не могу не думать, что что-то не так ... если я начну делать что-то подобное, у меня будут методы, обрабатывающие GET, заполненные if / else, ищущие отсутствующие параметры ...

Другие решения, о которых я подумал:

• включает отчеты в итоговые GET на mywebsite/api/users/{id}, но у меня много отчетов, так что в итоге все станет очень плохо ...
• отобразить другой URL только для этой функции, но он просто не выглядит правильным ...

Я только что понял эту вещь REST, мне нравится концепция, но небольшое объяснение этого вопроса действительно помогло бы мне лучше понять ее.

Спасибо

Edit:

Кажется, я столкнулся с общей проблемой в мире REST, я привязал свои ресурсы к модели. Если вы привязываете ресурс к модели, у вас возникают проблемы с совокупными атрибутами. Какой-то парень описывает эту ошибку здесь http://jacobian.org/writing/rest-worst-practices/, но я еще не понял, как справиться с этим, как он сказал ...

fyi Я использую django / поршень, но этот вопрос должен отвечать независимо от языка.

Answer 1

Я не могу не думать, что что-то не так ...

Единственное, что вы делаете неправильно, думает, что ваша структура URI делает ваше приложение более или менее RESTful. оригинальная литература REST никогда не говорит, что строки запроса плохие. Люди склонны зацикливаться на структуре URI и, похоже, считают, что ваши URI должны быть структурированы определенным образом, чтобы считаться RESTful. В использовании ?username=<username> нет ничего плохого. URI - это просто идентификатор (хотя некоторые могут быть более дружественными к человеку, чем другие) .

Итог: не зацикливайтесь на том, как выглядят ваши URI . Есть гораздо более важные вещи, на которые нужно обратить внимание (продвижение гиперссылок / гипермедиа, привязка к единому интерфейсу - обычно HTTP, кешируемость и т. Д.).

Это может быть большим отступлением, но, что касается вашего комментария о связи ресурсов с моделями, вы все еще в порядке. Если вы идете по пути / reports / ID / user, просто представьте «user» как имя отношения в вашей модели отчетов. Конечно, ваша модель определяет отношения между отчетом и пользователем. Вы можете просто проанализировать последнюю часть вашего URI, чтобы она соответствовала названию этого отношения. В случае отношения один к одному, как вы описали, всегда полезно установить заголовок Content-Location в соответствии с каноническим URI пользователя.

Например. Скажем, отчет 123 принадлежит пользователю 1. Теперь у вас есть два способа отослать этого пользователя:

http://example.com/reports/123/user
http://example.com/user/1

Для первого URI было бы также неплохо установить Content-Location: http://example.com/user/1 header

Answer 2

Вот как я бы это реализовал:

• mywebsite / api / users: возвращает список пользователей
• mywebsite / api / users / {id}: возвращает пользователя и связанную информацию, если пользователь существует, в противном случае 404
• mywebsite / api / users / {id} / reports: возвращает отчеты для конкретного пользователя, если существует, иначе 404
• mywebsite / api / users / {id} / reports / {id}: возвращает конкретный отчет для конкретного пользователя, если существует, в противном случае 404

---

• mywebsite / api / reports: возвращает список отчетов
• mywebsite / api / reports / {id}: возвращает отчет и связанную информацию, если она существует, в противном случае 404

НТН,

-Л