М
Друзья, всем привет!
Size: a a a
2020 July 02
М
Подскажите по архитектуре, как правильно реализовать работу с RestAPI? Я вижу это так: Создаём 1 класс в нём у нас хранится информация по серверу, токен клиента, отправка, получение ответа по запросу, сереадлизация и ТД. Далее я из других классов обращаюсь к этому и говорю ему куда и какой запрос нужно отправить и передаю ему модель, верная схема?
М
Под моделью я понимаю объект для отправки
М
Получив ответ я пересылаю его в класс, который делал отправку
М
И тут ещё вопрос, где лучше хранить ссылки на restURL в основном классе, который работает с сервером или каждая ссылка в своём классе?
SZ
Подскажите по архитектуре, как правильно реализовать работу с RestAPI? Я вижу это так: Создаём 1 класс в нём у нас хранится информация по серверу, токен клиента, отправка, получение ответа по запросу, сереадлизация и ТД. Далее я из других классов обращаюсь к этому и говорю ему куда и какой запрос нужно отправить и передаю ему модель, верная схема?
можно посмотреть сэмплы https://github.com/reactiveui/refit
М
можно посмотреть сэмплы https://github.com/reactiveui/refit
Спасибо, пойду изучать
М
можно посмотреть сэмплы https://github.com/reactiveui/refit
Блин, для меня это пока слишком сложный пример, может кто-то может объяснить доступней?
М
Всё, что я понял из этого кода, это что моя логика вроде правильная, но не на 100% уверен )
🦉
Блин, для меня это пока слишком сложный пример, может кто-то может объяснить доступней?
Для работы с любыми внешними сервисами предлагаю такой вариант:
1) За работу с каким-то сервером выделяется отдельный класс - ApiClient
2) Методы внутри него имеют доступ к Data Layer (используют модели на основе Json, например)
3) Каждый метод делает только одно действие с внешним API
4) ApiClient сам НЕ занимается тем, что реализует логику авторизации
5) ApiClient сам НЕ создаёт HttpClient
6) ApiClient получает все необходимые дополнительные сервисы в конструкторе при создании. Те он работает с уже готовыми HttpClient, которые в него прокинули.
7) В ApiClient стоит использовать один HttpClient на 1 сервер API. Если используется несколько серверов, куда есть доступ, лучше использовать по одной инстансе HttpClient на каждый сервис.
1) За работу с каким-то сервером выделяется отдельный класс - ApiClient
2) Методы внутри него имеют доступ к Data Layer (используют модели на основе Json, например)
3) Каждый метод делает только одно действие с внешним API
4) ApiClient сам НЕ занимается тем, что реализует логику авторизации
5) ApiClient сам НЕ создаёт HttpClient
6) ApiClient получает все необходимые дополнительные сервисы в конструкторе при создании. Те он работает с уже готовыми HttpClient, которые в него прокинули.
7) В ApiClient стоит использовать один HttpClient на 1 сервер API. Если используется несколько серверов, куда есть доступ, лучше использовать по одной инстансе HttpClient на каждый сервис.
🦉
Для работы с любыми внешними сервисами предлагаю такой вариант:
1) За работу с каким-то сервером выделяется отдельный класс - ApiClient
2) Методы внутри него имеют доступ к Data Layer (используют модели на основе Json, например)
3) Каждый метод делает только одно действие с внешним API
4) ApiClient сам НЕ занимается тем, что реализует логику авторизации
5) ApiClient сам НЕ создаёт HttpClient
6) ApiClient получает все необходимые дополнительные сервисы в конструкторе при создании. Те он работает с уже готовыми HttpClient, которые в него прокинули.
7) В ApiClient стоит использовать один HttpClient на 1 сервер API. Если используется несколько серверов, куда есть доступ, лучше использовать по одной инстансе HttpClient на каждый сервис.
1) За работу с каким-то сервером выделяется отдельный класс - ApiClient
2) Методы внутри него имеют доступ к Data Layer (используют модели на основе Json, например)
3) Каждый метод делает только одно действие с внешним API
4) ApiClient сам НЕ занимается тем, что реализует логику авторизации
5) ApiClient сам НЕ создаёт HttpClient
6) ApiClient получает все необходимые дополнительные сервисы в конструкторе при создании. Те он работает с уже готовыми HttpClient, которые в него прокинули.
7) В ApiClient стоит использовать один HttpClient на 1 сервер API. Если используется несколько серверов, куда есть доступ, лучше использовать по одной инстансе HttpClient на каждый сервис.
В последствии HttpClient может быть заменен на любой другой удобный rest клиент
🦉
В последствии HttpClient может быть заменен на любой другой удобный rest клиент
Например на Refit
SZ
а System.Text.Json пробовал кто в xamarin? Как успехи? У меня чот неймспейсы не видит
🦉
Например на Refit
Можно написать Extensions методы для HttpClient для удобной сериализации данных
🦉
И тут ещё вопрос, где лучше хранить ссылки на restURL в основном классе, который работает с сервером или каждая ссылка в своём классе?
🦉
Можете попробовать использовать эту библиотеку, которая в себе несёт только расширения для HttpClient
🦉
Но с удобной встроенной сериализацией/дессереализацией в структуры
🦉
Авторизацию стоит осуществлять через Handler который навешивают на HttpClient
🦉
Учитывая то, что подразумевается использовать по HttpClient на группу методов, то стоит так же разделить методы, которые требуют авторизации и использовать там HttpClient у которого есть Handler который подсовывает внутрь авторизацию
М
@maxspT спасибо, не уверен, что поняло правильно, но буду пробовать, может в процессе догоню, что и как )