Какой общепринятый порядок вызова исключений при обработке HTTP запроса?
Пишу веб сервис и столкнулся с проблемой следующего характера:
Вот у меня есть запросы вида
1. GET /items?param=value&... - получение итемов текущего пользователя
2. GET /items/{itemID} - получение по id
3. POST /items - создание нового
и т. д. и т. п. многоуровневая структура, все дела. Это упрощенный вид, в угоду наглядности.
Для 1 и 3 запросов мне точно нужна авторизация, а вот для 2-го не всегда (элементы могут быть приватными или публичными). Я паршу запрос сверху вниз, проверяя поэлементно, и не понятно в каком порядке расположить обработчики
1. Не валидный элемент пути (itemID), например там есть буквы, а должны быть только цифры (400)
2. Авторизация (401)
3. Аутентификация/Нет доступа к элементу (403)
4. Элемента не существует (404)
5. HTTP метод не используется (405)
6. Не знаю как назвать, но вдруг дальше по строке запроса бред, например /items/{itemID}/chupapimunyanya, а такого эндпоинта вообще нет. (тоже 404, но дальше) или это проблема следующей итерации?
7. Валидация параметров запроса (типа для этого эндпоинта не предусмотрен параметр "param" или для него значение "value" недопустимо)
8. Валидация тела запроса (проверка на корректность набора данных и соответствие типам)
Я полагаю, что 2 внутри 3 пункта в случае не обязательной авторизации
1 и 5 перед 3
7 и 8 в конце
то есть 1_5_4_3(2)_7_8 -- 6 в случае необязательной авторизации
и 1_5_2_4_3_7_8 -- 6 в случае обязательной
(Это из моих соображений, которые я не могу объяснить)
Но возникает проблема. Во-первых, с 6 пунктом. Я должен сначала сказать клиенту, что {itemID} кривой или что эндпоинта не существует? Во-вторых, корректно ли в случае обязательной авторизации сначала проверять 2й пункт, а затем 4-й ?
У меня возникла мысль, что стоит проверять в порядке нарастания сложности, то есть проверить, что путь существует или HTTP метод применим, проще, чем провалидировать параметр пути, а авторизация еще тяжелее, это уже отдельный запрос к бд, ну и т д. Но по такой логике 7 и 8 должны быть перед 2, 3 и 4 пунктами, а это как-то не логично.
Может есть какой общепринятый алгоритм? Сам я ничего осмысленного не смог накопать
Для правильного вопроса надо знать половину ответа
1. Валидация маршрута. Если мы не можем определить маршрут, то не можем на определить требуемые права, ни проверить валидность параметров.
2. Валидация формата данных.
3. Аутентификация пользователя - подтверждение, что пользователь действительно тот, за кого себя выдаёт.
4. Авторизация пользователя - определение списка прав.
5. Вызов метода, соответствующего маршруту. В нём проверка наличия данных и, при необходимости, проверка права пользователя на доступ к этим данным.
Петр, Теоретически может. Но тогда надо будет оформить столько бумажек и выполнить столько обязательных по закону действий, что вряд ли кто-то будет заморачиваться. К тому же, большая часть параметров запроса - идентификаторы, даты, числа, строки. Вряд ли вы сможете установить режим коммерческой тайны для общих типов данных.
Но, вообще, да, it depends. Состав и порядок действий может меняться в зависимости от конкретных задач.
Rsa97, Вы о бумажках, а я просто о конкурентах. Чтобы бесплатно скопировать не могли ))
Да и система становиться более безопасной, так как устраняются анонимные атаки на уязвимости по формату данных.
Здесь по мне так, к вопросу нужно подходить иначе, что чаще спрашивается то и раньше валидировать, т.е. эти пункты должны быть первыми и простыми. Потом по мере усложнения делить этапы по колличеству интераций и их сложности. Вот откуда здесь могут знать сколько у тебя юзеров и сколько у тебя itemID в bd. Может проще 404 отдать, если нет такого itemID, чем юзера искать.
Тут вопрос больше о том как "правильно" (или как принято), а не как логично. Есть ли какая-нибудь согласованность между популярными фреймворками?
С точки зрения быстродействия вопрос наверное даже глупый. Странно иметь 50% или хотябы 5% синтаксически некорректных запросов. Я к тому, что в 99.9% случаев, так или иначе, придется провести все эти проверки, прежде чем дойти до бизнес-логики. И не важно в каком порядке. Как известно, от перестановки мест слагаемых... ну да.
Хочется сделать хорошо, а тратить 2-3 недели на написание исследовательской работы просто не хватит сил. Может когда-нибудь, в будущем))))
