Есть ли какая-либо причина, почему?
Во многих случаях это удобнее, чем передавать заголовок аутентификации в качестве параметра каждому методу Retrofit, для которого нужен заголовок.
Например, предположим, что мы взаимодействуем с веб-службой, имеющей 123 456 789 конечных точек, к которым нам нужно обратиться.В соответствии с вашим планом нам необходимо:
- Добавить аннотированный параметр
@Header к 123 456 789 методам в нашем интерфейсе API Retrofit - Организовать передачу этого параметра во все наши вызовыэти 123 456 789 методов
Используя перехватчик, мы добавляем один перехватчик, и он охватывает все эти методы.
Потому что иногда у вас будет API, который не требует аутентификации(например, если у вас есть конечная точка состояния бэкэнд-системы)
Предположим, что 789 из этих конечных точек не нуждаются в аутентификации.Остальные 123 456 000 делают.В соответствии с вашим планом нам необходимо:
- Добавить аннотированный параметр
@Header к 123 456 000 методов в нашем интерфейсе Retrofit API - Организовать передачу этого параметра во все наши вызовыэти 123 456 000 методов
С помощью перехватчика нам нужен один перехватчик для обработки всего этого.Этот перехватчик может иметь некоторый белый список для определения того, какие конечные точки могут пропускать заголовок, используя:
- Регулярное выражение пути
- Соответствие сегмента пути
- Соответствие полного пути
- Независимо от того,
Очевидно, я немного шучу здесь, в том, что немногие веб-сервисы имеют 123 456 789 конечных точек.
Однако, есть некоторая точка безубыточности, когдаПерехватчик будет проще, чем обработка параметра @Header.Где эта точка безубыточности зависит от команды разработчиков.