теперь они сьезжаются, и нужно многое переосмыслить.
1️⃣) Предполагается иметь три уровня доступа к данным : публичный - для веб приложений, самый минимум только необходимой информации, для сторонних клиентов - по авторизации, только данные, представляющие ценность, и админитративный - наиболее полные данные с метаданными, вроде истории изменений редакторами. Имеет ли смысл явно делить это на уровне URL, если модели используются одни и те же, то есть api.site.com/admin/items, api.sute.com/v1/[api-code]/items ... , api.com/public/items-for-webapp , при условии, что и апи, и вебприложения делает одна компания? Имеет ли смысл вводить версионирование для чего-то кроме апи для сторонних пользователей?
2️⃣) В привычных мне рест-апишках роуты строились банально: сайт/[множество]/[идентификатор]. Теперь реализовали возможность получать статистику по множеству /[множество]/статистика[1,2...] , корректно ли это? Ведь статистика по множеству не возвращает члены множества, стоит ли её тогда выделить уровнем выше? апи.ком/статистика/[множество]/предмет-отчёта - например.
3️⃣) Естественно, я уже посмотрел несколько докладов с конференций на тему, и в одном из них звучала рекомендация препочитать snake_case для роутов апи кемелКейсу или ПаскальКейсу. В моём апи сейчас используются кебаб-кейс, есть причины изменить это?
по третьему пункту - в урлах лучше не юзать большие буквы - потому-что некоторым серверам на винде пофиг на регистр букв. Это вас конечно может не касаться - но как бы лучше за привычку взять) к апям не относиться - но сеошники говорят лучше урлы через тире писать
GraphQL вам в помощь! :)
Обсуждают сегодня