Wizards Api

Клиент к волшебному АПИ пожрали мозгошмыги. Репаро не помогает, вам нужно воскресить утерянное руками.

1. Для начала восстановим модели и сам клиент. В IWizardClient указаны базовый адрес АПИ и нужные методы. Постучитесь в АПИ с помощью Postman или Insomnia, чтобы узнать, как выглядят данные, и имплементируйте методы в WizardClient. Парочку моделей фантастические твари оставили невредимыми, какие-то методы сохранились в интерфейсе, но это нам не очень поможет. Пока не будем обращать внимания на сложность эликсиров и проигнорируем поле Difficulty. Также следует придерживаться Статута о Секретности и не злоупотреблять использованием единственного Post метода.
2. После того, как вернём доступ до данных, попробуем реализовать методы в WizardService. В нём описано, что именно нужно сделать и посчитать. Вам могут пригодиться ваши знания LINQ. Можно проверить с помощью WizardServiceTests. Закоменченные тесты пока не трогайте.
3. Попробуйте перейти по адресу. Это документация нужного нам АПИ, в формате swagger. Такая документация может генерироваться автоматически, что упрощает интеграцию с разными апишками. В этом json файле указаны все методы и модели АПИ. А значит мы можем наконец вспомнить про сложность эликсиров: попробуйте разобраться с форматом документации и найти в ней все возможные форматы для enum ElixirDifficulty и внести сложность в модель эликсира.
4. Пакет Swashbuckle может не только сгенерировать документацию вашего АПИ автоматически, но и запускать Swagger UI, для этого АПИ по адресу. На этой странице не только лежит вся информация в человекопонятном виде, на самом деле, запросы можно отправлять прямо с неё, чтобы понять, как работает конкретный метод и что он вернёт. Попробуйте, например, получить информацию о факультетах (Houses).
5. Дальше задания со звёздочкой. А что будет, если запросить у вашего клиента ингредиент с идентификатором, например, ingredient? Или волшебника с идентификатором de736ba2-3a67-4bce-b451-f40bac39fd03? А что возвращает сам АПИ на такие запросы? Поймите формат ошибок, восстановите модель ClientError. Посмотрите на класс ClientResult. Он может хранить StatusCode запроса и ответ или ошибку запроса. Попробуйте возвращать из клиента не конкретные модели, а обёртку над ними - ClientResult<TResponse>. Это значит, что программист, который вызывает метод вашего клиента, сможет понять, был ли запрос успешным или нет, и предпринять что-то в зависимости от результата. Т.е. можно удостовериться, что запрос удался с помощью EnsureSuccess, чтобы выбросить исключение, если что-то пошло не так. Или же уточнить, успешен ли запрос с помощью IsSuccessful и, например, пропустить неуспешный запрос, никак не обрабатывая его результат.
6. Вернёмся к закоменченным тестам. Нужно изменить WizardService. Метод CountIngredientUsagesAsync должен бросать исключение с сообщением, в котором должен быть title из возвращённой АПИ ошибки, если с поиском ингредиента что-то пошло не так. Оставшиеся два метода должны возвращать 0, если где-то что-то не нашлось.

И немного мудрости от профессора Дамблдора: "Счастье можно найти даже в самые темные времена, если не забывать обращаться к свету".