@bondle

На сколько глубоко могут уходить подколлекции в нэйминге URI в REST?

Представим, у нас есть аккаунт, мы получаем его через
/accounts/:id
У аккаунта есть профиль
/accounts/:id/profiles/:id
У профиля есть тэги
/accounts/:id/profiles/:id/tags

И теперь я хочу сделать апишку для получения информации о каждом тэге. Или хочу его изменить. С одной стороны мы можем использовать
GET /accounts/:id/profiles/:id/tags/:id
Но что если у тэга есть еще подколлекции? Цвет (и пускай внутри цвета еще набор для простоты). В конце концов мы можем получить
GET /accounts/:id/profiles/:id/tags/:id/color/:id/more-fields/:id/more-fields/:id/more-fields/:id ....

В конце-концов мы будем иметь очень длинный uri. Из-за этого очень хочется что-то выкинуть. Например /accounts и получить
GET /profiles/:id/tags/:id/color/:id/more-fields/:id/more-fields/:id/more-fields/:id ....


Я понимаю, что в таком случае мы теряем возможность создать какую-то еще сущность profile не относящуюся к /accounts. Но что если "скорее всего этого не произойдет, а если произойдет назовем по другому"?
На сколько плохая практика выкидывать ведущие ресурсы из длинных uri? На сколько у вас они длинными получаются? А что если в конце концов он будет приближаться к лимиту на длину url строки (в особенности с гет параметрами)?
  • Вопрос задан
  • 57 просмотров
Пригласить эксперта
Ответы на вопрос 3
@bacon
тут вопрос насколько уникально вложенная id, если уникально, то убирать родителей /accounts/:id/profiles/:id -> /profiles/:id

а тут похоже на фильтрацию
/accounts/:id/profiles/:id/tags/:id/color/:id/more-fields/:id/more-fields/:id/more-fields/:id
->
/profiles/:id/tags/?color=:id&more-fields=:id&more-fields=:id&more-fields=:id


На сколько плохая практика выкидывать ведущие ресурсы из длинных uri?
всегда стараюсь выкидывать, оставлю только в случаях, когда id не обеспечивает уникальности (такое очень редко бывает)

А что если в конце концов он будет приближаться к лимиту на длину url строки (в особенности с гет параметрами)?
помню очень давно поднимался такой вопрос, у одной крупной конторы, был api где при множестве параметров, они уперлись в лимиты длины url на GET запросе, тупо разрешили его делать как POST.
Ответ написан
Комментировать
@calculator212
На сколько глубоко могут уходить подколлекции в нэйминге URI в REST?
До 2к символов, в целом написание таких длинных запросов не противоречит идеологии rest, т.к. rest это не про то какой длины должен быть url, а про стиль взаимодействия.
:id/profiles/:id/tags/:id/color/:id/more-fields/:id/more-fields/:id/more-fields/:id
Конкретно в этом случае используется странное решение(на мой взгляд), и не совсем понятно зачем так делать, т.к. задавать это все через параметры проще. Но т.к. rest это просто стиль архитектуры, то вам никто не запретит так делать, но если кому-то достанется такой код, то он будет не в восторге.
И теперь я хочу сделать апишку для получения информации о каждом тэге. Или хочу его изменить. С одной стороны мы можем использовать
GET /accounts/:id/profiles/:id/tags/:id
в данном случае возможно имеет еще смысл таких url до 2-го id на id тегов уже явно бесполезно и его проще задать параметром, хотя можно сделать, чтобы только id аккаунта был в url, всё остальное можно засунуть в параметры, но тут я не знаю архитектуры приложения, возможно вам так удобнее или проще.
Ответ написан
yarkov
@yarkov
Проект "Жизнь после смерти" - lifeafterdeath.ru
На сколько у вас они длинными получаются?

Я вообще не использую вложенные сущности. У меня всё отдельно:
# Новость
/news/:id
# Комментарии к новости
/comments?newsId=123
#  Ещё вариант, чтобы не делать второй запрос за комментариями
/news/:id?relations[]=comments

А то и правда можно увлечься ))
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы