Является ли ресурс не-единственного ресурса RESTful?

Question

Зачастую при разработке REST API я вижу общую схему /resourceA/{id}/resourceThatBelongsToA.

Можно ли делать /resourceA/resourcesThatBelongToA при разработке API?

Пример Reallife

Скажем, у меня есть веб-приложение, похожее на StackOverflow.Есть вопросы, и каждый вопрос имеет статус accepted или not accepted.

Я предоставляю конечную точку /questions/{id}/status, чтобы пользователи могли определить, есть ли у вопроса принятый ответ.

Затем я сталкиваюсь с проблемой желания найти все вопросы, на которые есть приемлемый ответ.Затем я определяю конечную точку /questions/statuses?status=accepted.Эта конечная точка, если не заданы параметры запроса, перечислит все статусы всех вопросов (с разумными ограничениями на количество возвращаемых статусов, скажем, 100).Однако, когда мне дан фильтр типа состояния, я могу определить все вопросы, на которые есть ответ, который был принят.

Мне кажется, что это практичный дизайн, который хорошо подходит для варианта использования.

Это приемлемый шаблон для использования или есть что-то более подходящее?

Answer 1

Можно ли делать / resourceA / resourcesThatBelongToA при разработке API?

Да.

REST не волнует, какое правописание вы используете для своих идентификаторов. REST не заботится о том, как вы организуете свою иерархию ресурсов.

Это приемлемый шаблон для использования или есть что-то более подходящее?

Эвристика, которую я рекомендую, заключается в следующем: «Вы бы сделали это таким образом с веб-сайтом?» Если ответ «да», то вы на правильном пути.

Answer 2

REST API выглядят хорошо, когда у вас есть уникальный идентификатор для родительского ресурса, с которым вы имеете дело. /questions/{id} хорошо, если вы хотите получить ресурс с конкретным идентификатором. Но если у вас нет уникального идентификатора и если ответом будет набор ресурсов, то это всего лишь фильтр, примененный к родительскому ресурсу.

Так что для вашего случая API может быть

/questions?status=accepted

Если вы хотите, чтобы потребители API получали гибкость при выборе пределов, вы можете использовать для этого параметр запроса limit .

/questions?status=accepted&limit=10