Как сделать REST Api удобным в написании и дальнейшей поддержке?

Question

[Антон Уланов]

Доброе время суток. Направьте меня в правильное русло если я сбился с курса :) хочу написать рест сервис но для большого количества функций. Сейчас я думаю писать все в router api.js который будет отвечать за модуль todo, calendar и так далее. И тут я засомневался правильно ли все пихать в один route или же лучше разделить на apitodo apical и так далее. Заранее спасибо за ответы

Answer 1

[Andrey Dyrkov]

Стоит выделить все роуты в отдельную папку и разбивать их по файлам. Для доступа к данным нужно какую-то оболочку написать, чтобы изменив базу данных или схему, это не повлияло на работу API. Всегда гуглите "лучшие практики", обычно люди деляться своим опытом с другими и этим можно пользоваться, чтобы не делать плохо :)
Вот например.

Comments

[Антон Уланов]

тоесть если я в папке router создам подкаталог api в котором в свое время я создам подкаталоги todo, cal и так далее где будут храниться роуты я не вызову гнев сатаны :) и смогу вызывать из api.js роуты из каталогов todo и так далее?

[Andrey Dyrkov]

Антон Уланов: ну вот каждый файл это модуль, вы просто создаёте файл типа routes.js в нём подключаете другие файлы модули ( роуты ), можите сделать специальный метод .register который будет принимать объект express приложения. Сам модуль будет получать это приложение и добавлять новый роут к нему. Можите сделать цепочку вызовов register, если он будет возвращать приложение. Как хотите так и делайте, главное чтобы можно было быстро разобраться :)

[Andrey Dyrkov]

Антон Уланов: роуты храните там где корень API приложения, где модели и тд.

[Антон Уланов]

спасибо :)

Answer 2

[Сергей Протько]

1) пишем тесты на API
2) делаем как удобно, пока у нас есть тесты мы можем быстро подправить.

Отдельно рекомендую глянуть jsonapi.org

Comments

[Антон Уланов]

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

[Сергей Протько]

Антон Уланов: это впервую очередь стандарт описания API, в котором решены кучи проблем. Из него как минимум стоит черпать идеи.

[Антон Уланов]

я учту это :)