Стоит ли один и тот же endpont в RESTlike API делать доступным и для авторизованного и не авторизованного пользователя?

Question

[Gruzchick]

Здравствуйте.

Допустим я хочу сделать, апи блог-платформы. Предоставляю консюмерам такой ендпоинт:

/blogs?usrId={someValue}&filter[published]={someValue}

И теперь вынужден в коде рассмотреть несколько вариантов, а именно:
Авторизованный или не авторизованный запрос = 2 варианта
Указан uresId или нет = 2 варианта
Значения filter[published] : undefined, true, false = 3 варианта

В итоге надо рассмотреть 2*2*3 = 12 случаев и выдавать либо данные либо ошибку авторизации.

Меня смущает что надо столько условий проверять, в одном контроллере это нормально? Или есть какой то другой способ организации такой логики, допустим сделать два ендпоинта, но тогда как их назвать?

Выскажите свои соображения пожалуйста?

UPD:
Вот такое пришлось написать:

const {
      userId,
      filter: { published },
    } = params;

    const qb = this.blogRepository
      .createQueryBuilder()
      .select(['id', 'title', '"createdAt"'])
      .addSelect('SUBSTRING(body, 1, 300)', 'body');

    if (currentUser) {
      // request authorized
      if (userId) {
        qb.where('"userId" = :userId', { userId });
        if (published === Published.unpub) {
          if (currentUser.id === userId) {
            qb.andWhere('published = :published', { published });
          } else {
            throw new UnauthorizedError();
          }
        } else if (published === undefined) {
          if (currentUser.id !== userId) {
            qb.andWhere('published = :published', {
              published: Published.pub,
            });
          }
        } else {
          qb.andWhere('published = :published', {
            published: Published.pub,
          });
        }
      } else {
        if (published === Published.unpub) {
          qb.where('published = :published', { published }).andWhere(
            '"userId" = :userId',
            { userId: currentUser.id }
          );
        } else if (published === undefined) {
          qb.where('published = :published', {
            published: Published.pub,
          }).orWhere(
            new Brackets((qb1) => {
              qb1
                .where('published = :published', { published: Published.unpub })
                .andWhere('"userId" = :userId', { userId: currentUser.id });
            })
          );
        } else {
          qb.andWhere('published = :published', { published });
        }
      }
    } else {
      // request not authorized
      if (userId) {
        qb.where('"userId" = :userId', { userId });
        if (published === Published.unpub) {
          throw new UnauthorizedError();
        } else {
          qb.andWhere('published = :published', { published: Published.pub });
        }
      } else {
        if (published === Published.unpub) {
          throw new UnauthorizedError();
        } else {
          qb.andWhere('published = :published', { published: Published.pub });
        }
      }
    }

Всем спасибо за внимание.

Answer 1

[⚡ Kotobotov ⚡]

если нужно 12 логических вариантов реализовать, то прийдется их реализовывать, другое дело что используют подходы ускоряющие их реализацию:
обычно схема такая, ты свой запрос "наследуешь" от какого-то объекта с уже заготовленной ОБЩЕЙ функциональностью для запросов, например на проверку авторизации и возврат соответствующих ошибок.
а специфичные для запроса параметры парсишь, ну и в случае их отсутствия заменяешь на параметры по умолчанию и работаешь как работал, либо там какие-то ошибки выдаешь

Comments

[Gruzchick]

У меня правильный или нет передан токен, проверяет мидлвар. А остальное придётся ручками значит

[⚡ Kotobotov ⚡]

Gruzchick, ну ты просто отсутствующие параметры при парсинге замени на параметры по умолчанию и все будет проще.

Answer 2

[kafkiansky]

Делать разные ендпоинты не стоит, лучше сделать JWT авторизацию и тогда ваши проверки сократятся в 2 раза.

Comments

[Gruzchick]

У меня итак JWT. Просто может передаваться заголовок с токеном а может не передаваться. Как это сократит проверки?

[kafkiansky]

Gruzchick, не авторизованный пользователь имеет доступ к ендпоинту и может им пользоваться? Если нет, то там не будет 2-х проверок, там одна:

if (!$token) {
     throw new AccessDeniedException();
}

[Gruzchick]

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

Answer 3

[Иван Шумов]

Вам надо переосмыслить ваше API. Оба варианта пока что кажутся дикостью. Если детализируете что у вас за api, что делает этот конкретный метод то тогда можно помочь принять решение.

Вообще:
- выделите сущности системы (Entities of Domain Model хотябы)
- составьте список ролей и действий, которые они делать (UseCase)
- вот тут начнет проясняться

Comments

[Gruzchick]

Есть только пользователи и блоги. Блоги могут быть опубликованными или нет. Из пред идущего ясно в каких случаях пользователь может смотреть блоги а в каких нет. Надо реализовать такой ендпоинт. Всё.

[Иван Шумов]

Gruzchick, отлично, значит у вас основная проблема - разделение блогов по публикации. Тогда почему бы не вынести неопубликованные в отдельный эндпоинт?

[Gruzchick]

Иван Шумов, А как тогда на фронте будет реализован виджет, со списком блогов, у которого есть фильтры по "userId" и по "published", пользоваться им может как авторизованный так и нет, и пагинация нужна. Не получится ли в итоге что я всю сложность реализации перевалю на плечи фронтендеров, усугубив это ещё и тем что на фронтенде с таким бекендом, это реализовать будет труднее? Или я преувеличиваю? Оговорюсь сразу я новичок.

[Иван Шумов]

Gruzchick, есть такой подход - backend for frontend. То есть реализация API под нужды frontend. Делайте те эндпоинт юты, что нужны бэку. Сделайте их, например:
GET /posts
GET /user/: username/posts
GET /user/: username/posts/drafts

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

[Иван Шумов]

Gruzchick, если вы не знаете какой будет фронт то вы либо должны иметь четкое ТЗ, либо должны сесть общаться с теми кто его будет делать. Не верю что бы делаете SaaS или BaaS

[Gruzchick]

Иван Шумов,

составляет каждый свой набор параметров для единой компоненты

не понял что значит единая компонента?

backend for frontend

по этой теме почитаю, спасибо за тег

Как вот быть в случае если я не знаю какой фронтенд будет? API публичное.

[Gruzchick]

Иван Шумов, Я вам честно скажу я делаю просто, проект учебный, сидя на работе в магазине аккумуляторов, хочу стать программистом, зарабатывать этим. И вот я наткнулся на то, что даже такой простой роут чтобы реализовать, надо, попотеть. А компании часто высылают тестовое задание с примерно таким функционалом, только объёмнее ). Я в ответ говорю, что если делать качественно, то можно неделю и две провозится. И ещё при этом не получить не чего. На что люди меня просто не берут на работу. И вот я хочу сделать заранее, несколько проектиков, чтобы их предлагать как тестовые ).

[Иван Шумов]

Gruzchick, тогда вы не с той стороны подошли. В этой жизни, наверное, только философы решают абстрактные задачи. Делайте все в комплексе, но по частям. Опишите сущности и из составляющие, определитесь как будет выглядеть фронт ( я не про дизайн, а технологии и действия, список экранов) и как он будет получать данные и только после этого начинайте проектировать API. Чтобы решать сферическую задачу в вакууме нужно иметь очень много опыта)

[Gruzchick]

Иван Шумов, Я бы назвал это решение в общем виде. Лёгкое я итак знаю, что могу сделать. И мне это ничего не даст. А вот рассуждения над таким фильтром, заставили меня подумать об ограничениях языка, построителя запросов ормки, ограничениях SQL. Помимо всего прочего, я подумал было бы неплохо (а может уже есть просто я найти не могу) в SQL иметь такое WHERE или такой тип данных:
WHERE some = someValue
Чтобы при передаче в someValue определённого значения
some = someValue
Не устанавливалось, это типа значения сброса фильтра. Но я уже не помню нафг мне нужна была такая фича )

[Иван Шумов]

Gruzchick, нужно лучше узнать про SQL и PDO

[Gruzchick]

Иван Шумов, Спасибо, посмотрю.