Предположим, у нас есть конечная точка books, в которую мы можем возвращать сериализованные объекты Book. Большинство времени, это книги, которые уже опубликованы (поэтому future опущено), а большинство времени мы будем отображать список книг , принадлежащий какой-то пользователь.(таким образом, пользовательский параметр в основном присутствует, и мы в основном фильтруем книги, принадлежащие какому-либо пользователю)
Пример запроса:
http://localhost:8000/api/books?future=true
http://localhost:8000/api/books?user=somebody
http://localhost:8000/api/books?future=true&user=somebody
Мне интересно, выглядит ли приведенная выше структура нормально.Другие идеи, некоторые кажутся хуже других, пришли на ум.Например, другая необязательная конечная точка / путь (вместо первого):
// this makes the least sense to me
http://localhost:8000/api/books/somebody?future=true
Я также размышлял, имеет ли смысл получать эти книги с конечной точки users:
http://localhost:8000/api/users/somebody/books
http://localhost:8000/api/users/somebody/books?future=true
И тогда я также могу позвонить:
http://localhost:8000/api/users/somebody/settings
Согласны ли вы, что второй вариант не имеет смысла?
Могут ли первый и третий примеры жить рядом друг с другом?
Полагаю, я действительно спрашиваю: возможно ли достичь одинаковых ресурсов двумя разными способами в дизайне REST?Как вы предпочитаете одно над другим?Когда вы применяете только один?когда вы разрешаете оба (если вообще)?
В этом случае конечные точки API будут использоваться будущим приложением для iOS, разработанным мной, но я не думаю, что это должно иметь отношение к вопросу.