Я разрабатываю приложения iOS уже довольно долгое время. Но в конце концов я никогда не был доволен дизайном архитектуры моего сетевого уровня. Особенно, когда речь идет о подключении API.
Здесь существует возможный дубликат, но я думаю, что мой вопрос более конкретный, как вы увидите.
Лучшие архитектурные подходы для создания сетевых приложений iOS (клиенты REST)
Я не ищу ответов, как "использовать AFNetworking/Alamofire". Этот вопрос не зависит от того, какая сторонняя структура используется.
Я имею в виду, часто у нас есть сценарий:
"Разработайте приложение X, которое использует API Y"
И это включает в себя в основном те же самые шаги - каждый раз.
- Внедрить логин/регистрацию
- Вы получаете токен аутентификации, сохраните его в цепочке ключей и добавьте в каждый вызов API
- Вам необходимо повторно аутентифицировать и повторно отправить запрос API, который не удалось выполнить с помощью 401
- У вас есть коды ошибок для обработки (как обрабатывать их централизованно?)
- Вы реализуете различные вызовы API.
Одна проблема с 3)
В Obj-C я использовал NSProxy
для перехвата каждого вызова API перед его отправкой, повторной аутентификации пользователя, если токен истек, и уволил фактический запрос.
В Swift у нас было несколько NSOperationQueue
, где мы поставили в очередь вызов auth, если мы получили 401 и поставили в очередь фактический запрос после успешного обновления. Но это ограничило нас использованием Singleton (чего мне не очень нравится), и нам также пришлось ограничивать одновременные запросы до 1.
Мне больше нравится второй подход - но есть ли лучшее решение?
Относительно 4)
Как вы обрабатываете коды статуса http? Вы используете много разных классов для каждой ошибки? Вы централизуете общую обработку ошибок в одном классе? Вы справляетесь с ними все на одном уровне или вы уловите ошибки сервера раньше? (Возможно, в вашем API-интерфейсе любой сторонней библиотеки)
Как разработчики пытаются решить эти проблемы? Вы поняли дизайн "лучшего совпадения"? Как вы тестируете свои API? Особенно, как вы это делаете в Swift (без реальной издевательской возможности?).
Конечно: каждый случай использования, каждое приложение, каждый сценарий различны - нет "Одно решение подходит для всех". Но я думаю, что эти общие проблемы повторяются так часто, поэтому я соблазнился сказать "Да, для этих случаев - может быть одно и несколько решений, которые вы можете использовать каждый раз".
С нетерпением ждем интересных ответов!
Приветствия
Орландо 🍻