Какие маршруты выбрать для REST API?

Question

Я разрабатываю успокоительный API с помощью NodeJS. Чтобы дать вам немного больше информации в моей заявке:

Моя заявка содержит обзоры. Опрос содержит вопросов, которые, в свою очередь, имеют .

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

Теперь для маршрутов API. Что было бы лучше:

Вариант 1

1. /API/отделы
2. /API/опросы
3. /API/вопросы
4. /API/выбор

Вариант 2

1. /апи/отделы
2. /апи/отделы/department_id/обзоры
3. /API/отделы/department_id/обзоры/survey_id/вопросы
4. /API/отделы/department_id/обзоры/survey_id/вопросы/question_id/варианты

Последний выглядит более логичным, потому что мне не нужно указывать идентификатор родителя в теле сообщения.

Что лучше всего использовать в качестве конечных точек?

Answer 1

Я не думаю, что между ними есть «лучшая практика»; скорее, речь идет о том, что интерфейс имеет наибольший смысл для вашего приложения. # 2 имеет наибольший смысл, если вы обычно собираетесь получать доступ к опросам на основе каждого отдела, а также имеет смысл с точки зрения доступа к вопросам на основе опроса.Если вы хотите устранить в-отделе часть, вы могли бы сделать что-то вроде смеси выше:

1. /апи/отделы
2. /API/опросы
3. /API/обзоры/survey_id/вопросы
4. /API/обзоры/survey_id/вопросы/question_id/опции

Если Вы ДЕЙСТВИТЕЛЬНО хотите ехать за отделом, я бы изменить # 2 так, что вместо/API/отделов/опросы можно было бы получить доступ к/API/отделы/department_id/обзоры ...

Но без зная больше о приложении, трудно понять, какой лучший ответ.

Answer 2

Есть ли в опросах какие-либо вопросы помимо вопросов? вопросы не содержат ничего, кроме выбора? Поэтому я спрашиваю, что если ответ на оба нет, то я бы на самом деле предпочитаю что-то вроде этого:

1. /api/departments/ # возвращает список отделов
2. /api/departments/<survey-id>/ # возвращает список вопросов
3. /api/departments/<survey-id>/<question-id>/ # возвращает список вариантов
4. /api/departments/<survey-id>/<question-id>/<choice-id> # возвращает список опций

или что-то в этом роде. В принципе, мне нравится придерживаться концепции «контейнеров» и «данных». Мне нравится думать об этом как о файловой системе.

Итак, если концепция заканчивается на «s», это контейнер (и я хочу, чтобы маршрут заканчивался символом «/», чтобы указать, что он действует как папка, но это нит).

Любой доступ к «/» приводит к элементу этого индекса, который, конечно, может быть другим контейнером. Подобно структуре каталогов в файловой системе. Например, если бы я лежал их в файловой системе, я мог бы придумать что-то вроде этого:

+ /api/departments/ 
|-----------------/human-resources/ 
        |---------------/survery-10/ 
            |----------/choice-10 

Answer 3

Выбор зависит от того, ресурсы принадлежат или совместно ресурсами более высокого уровня ; хотите ли вы каскадировать удаление или нет. Если вы владеете (с каскадным удалением), выберите вариант 2 и, если общий, выберите вариант 1.

Если опрос удален, я думаю, вы хотите удалить с него все вопросы и варианты (каскадное удаление). Это хорошо совпадает с вариантом 2, так как при удалении ресурсов/API/отделов/DepartmentID/обзоров/surveyid, вы, естественно, также удалить все subresources/API/отделы/DepartmentID/обзоров/surveyid/вопросы/....

С другой стороны, если вы хотите иметь возможность делиться вопросами между несколькими опросами и обмениваться опросами между несколькими отделами, то вариант 1 лучше.

Конечно, у вас также может быть сочетание варианта 1 и варианта 2, если некоторые типы ресурсов принадлежат друг другу, а другие - совместно.