Развивающийся ландшафт протоколов API
Обзор шести самых популярных протоколов API
REST
Webhooks
GraphQL
SOAP
WebSocket
gRPC
источник https://t.me/itmozg/9692
Обзор шести самых популярных протоколов API
REST
Webhooks
GraphQL
SOAP
WebSocket
gRPC
источник https://t.me/itmozg/9692
Добрый день, уважаемые форумчане.
Несколько дней назад, в поисках ответа на вопрос я попал на страницу с вопросом годичной давности одного пользователя, в которой он искал ментора, потому что сам не мог решить свой вопрос. В коментариях ему посоветовали выложить все задание здесь на pikabu. По причине отзывчивости и доброжелательного отношения пользователей я решил выложить свой вопрос, в надежде получить ответы.
Я рассылаю резюме на вакансию Python-разработчика, и получил тестовое задание. Хотя уже понимаю, что знаний моих не достаточно и нужно еще учиться и скорее всего в эту компанию меня не возьмут, но считаю обязаностью все тестовые задания решать . По причине самостоятельного обучения прошу строго не судить за вопросы, ответы на которые могут показаться очевидные.
И так задание:
Необходимо создать сервер авторизации и новостей с комментариями и лайками на Django с использованием RestFramework на python 3.
У каждого пользователя может быть две роли – пользователь и админ, админ может зайти в админ-панель, пользователь – нет. Как именно решить эту задачу не принципиально. Плюсом будет создание кастомного класса для авторизации наследуемого от BaseAuthentication - нам важно видеть как вы решите эту задачу.
Каждый пользователь может создать новость. Все пользователи могут получать списки всех новостей с пагинацией. Пользователи могут удалять и изменять свои новости. Админ может удалять и изменять любую новость.
Также нужно добавить механизм лайков и комментариев новостей – лайкать и комментировать может любой пользователь, автор может удалять комментарии к своим новостям, админ может удалять любые комментарии.
При получении списка новостей и одной конкретной новости нужно показать количество лайков и комментариев. Плюсом будет добавление списка последних 10 комментариев при получении списка новостей и одной новост.
Плюсом будет реализация механизма через микросервис.
Исходный код приложения необходимо выложить на GitLab или GitHub и запустить сервер. Сервер должен быть доступен для запросов из внешней сети, доступ к серверу (IP или доменное имя) а также роут для доступа к АПИ должны быть в README.md репозитория.
Краткий мануал по созданию виртуального сервера на базе яндекс.облака для новых пользователей даётся бесплатный период использования:
https://cloud.yandex.ru/docs/compute/quickstart/quick-create-linux
Также бесплатный сервер t2 micro можно поднять на Amazone:
https://us-east-2.console.aws.amazon.com/ec2/v2/home
Желательно:
контейнеризация в Docker
использование python venv
использование web сервера CherryPy, gunicorn и им подобных (какого-нибудь одного)
демонстрация понимание механизма миграций моделей (можно сделать несколько изменений в какой-либо модели и показать миграции)
использование .env файла для хранения информации о подключении к базе данных
файл README.md с описанием скриптов для разворачивания окружения и запуска сервера
Модели:
Users (имя пользователя, пароль в зашифрованном виде)
News (дата новости, заголовок новости, текст новости, автор)
Comments (Дата комментария, текст комментария, автор)
Опционально: Tokens (при авторизации можно создавать токены и хранить их в базе или использовать JWT токены)
Роуты
POST auth (передаем имя пользователя и пароль, получаем токен если пользователь с таким паролем есть и ошибку, если такого пользователя нет)
GET news (получаем список новостей с пагинацией)
POST news (создаем новость, проверка на авторизацию)
PUT news (обновляем новость, проерка на атворизацию, проверка на наличие прав)
DELETE news
GET comments (получение списка комментариев новости с пагинацией)
POST comments (создание нового комментария, проверка на авторизацию)
DELETE comments
Админка
Нужна стандартная админка Django (пользователи админки могут не пересекаться с пользователями в таблице Users)
Что мне непонятно:
1. Первое на чем я застрал это модель Users. Что мне нужно делать, использовать встроенную модель Django - User или создавать свою? Можно расширить джанговскую или создать прокси модель. Но я не понимаю, как хранить пароль, какой тип поля выбирать для этого? На даном этапе я создал модель News c полем ForeignKey(User).
2. Правильно ли я понял, что для выполнения задания создавать html-шаблон для отображения новостей не нужно? Хотя наверное это будет плюсом.
3. Для реализации механизмов коментариев и лайков в качестве микросервиса, нужно создать его как отдельное Django-приложение, а потом оформить как пакет и выкладывать на отдельном сервере?
4. В начале я пытался в качестве веб-сервера прикрутить CherryPY, но нашел только инструкции 10-летней давности. В итоге запускаю через Gunicorn, для него инструкция в документации Django. После запуска в админке Django, не отображалась статика, поэтому я установил Nginx. Это правильная последовательность действий или нужно было по другому делать?
5. Когда я сделаю проект, Nginx нужно устанавливать в Docker с остальными зависимостями? Создание докер-образа это одна задача, а разворачивание на сервере другая, или можно этот образ развернуть на сервере?
6. Еще читал, что плохая практика пихать в один образ Django-проект и БД, как лучше поступить в моем случае?
Заранее спасибо за ответы.
P.S. я откликался на вакансию Мидла, поэтому вариант задавать все эти вопросы рекрутеру с последующей переадресацией спецам я не рассматривал.
Резюме сегодня читал.
Сперва подумал, что человек перепутал раздел навыки и хобби, а потом как понял...
Их есть у нас! Красивая карта, целых три уровня и много жителей, которых надо осчастливить быстрым интернетом. Для этого придется немножко подумать, но оно того стоит: ведь тем, кто дойдет до конца, выдадим красивую награду в профиль!
Я преподаватель английского - веду свой видеоблог. Сегодня новая серия "HOW TO" посвящена семейному отдыху. Надеюсь будет интересно и подтянет ваш английский. Чтоб не было скучно, видео разбавлено веселыми скетчами. В ролях - вся моя семья. Видео с субтитрами, говорю в среднем темпе, с четкой дикцией, чтоб было понятно даже начинающим.
Продолжаем серию материалов про создание системы заметок. В этой части мы спроектируем и разработаем RESTful API Service на Go cо Swagger и авторизацией. Будет много кода, ещё больше рефакторинга и даже немного интеграционных тестов.
В первой части мы спроектировали систему и посмотрели, какие сервисы требуются для построения микросервисной архитектуры.
Исходники проекта — в репозитории на GitHub.
Подробности в видео и текстовой расшифровке под ним.
Прототипирование
Начнём с макетов интерфейса. Нам нужно понять, какие ручки будут у нашего API и какой состав данных он должен отдавать. Макеты мы будем делать, чтобы понять, какие сущности, поля и эндпоинты нам нужны. Используем для этого онлайн-сервис NinjaMock. Он подходит, если макет надо сделать быстро и без лишних действий.
Страницу регистрации сделаем простую, с четырьмя полями: Name, Email, Password и Repeat Password. Лейблы делать не будем, обойдемся плейсходерами. Авторизацию сделаем по юзернейму и паролю.
После входа в приложение пользователь увидит список заметок, который будет выглядеть примерно так:
Интерфейс, который будет у нашего веб-приложения:
- Слева — список категорий любой вложенности.
- Справа — список заметок в виде карточек, который делится на два списка: прикреплённые и обычные карточки.
- Каждая карточка состоит из заголовка, который урезается, если он очень длинный.
- Справа указано, сколько секунд/минут/часов/дней назад была создана заметка.
- Тело заголовка — отрендеренный Markdown.
- Панель инструментов. Через неё можно изменить цвет, прикрепить или удалить заметку.
Тут важно отметить, что файлы заметки мы не отображаем и не будем запрашивать у API для списка заметок.
Полная карточка открывается по клику на заметку. Тут можно сразу отобразить полностью длинный заголовок. Высота заметки зависит от количества текста. Для файлов появляется отдельная секция. Мы их будем получать отдельным асинхронным запросом, который не помешает пользователю редактировать заметку. Файлы можно скачать по ссылке, также есть отдельная кнопка на добавление файлов.
Так будет выглядеть открытая заметка
В ходе прототипирования стало понятно, что в первой части мы забыли добавить еще один микросервис — TagsService. Он будет управлять тегами.
Определение эндпоинтов
Для страниц авторизации и регистрации нам нужны эндпоинты аутентификации и регистрации соответственно. В качестве аутентификации и сессий пользователя мы будем использовать JWT. Что это такое и как работает, разберём чуть позднее. Пока просто запомните эти 3 буквы.
Для страницы списка заметок нам нужны эндпоинты /api/categories для получения древовидного списка категорий и /api/notes?category_id=? для получения списка заметок текущей категории. Перемещаясь по другим категориям, мы будем отдельно запрашивать заметки для выбранной категории, а на фронтенде сделаем кэш на клиенте. В ходе работы с заметками нам нужно уметь создавать новую категорию. Это будет метод POST на URL /api/categories. Также мы будем создавать новый тег при помощи метода POST на URL /api/tags.
Чтобы обновить заметку, используем метод PATCH на URL /api/notes/:uuid с измененными полями. Делаем PATCH, а не PUT, потому что PUT требует отправки всех полей сущности по спецификации HTTP, а PATCH как раз нужен для частичного обновления. Для отображения заметки нам ещё нужен эндпоинт /api/notes/:uuid/files с методами POST и GET. Также нам нужно скачивать файл, поэтому сделаем метод GET на URL /api/files/:uuid.
Структура репозитория системы
Ещё немного общей информации. Структура репозитория всей системы будет выглядеть следующим образом:
В директории app будет исходный код сервиса (если он будет). На уровне с app будут другие директории других продуктов, которые используются с этим сервисом, например, MongoDB или ELK. Продукты, которые будут использоваться на уровне всей системы, например, Consul, будут в отдельных директориях на уровне с сервисами.
Разработка сервиса
Писать будем на Go
- Идём на официальный сайт.
- Копируем ссылку до архива, скачиваем, проверяем хеш-сумму.
- Распаковываем и добавляем в переменную PATH путь до бинарников Go
- Пишем небольшой тест проверки работоспособности, собираем бинарник и запускаем.
Установка завершена, всё работает
Теперь создаём проект. Структура стандартная:
- build — для сборок,
- cmd — точка входа в приложение,
- internal — внутренняя бизнес-логика приложения,
- pkg — для кода, который можно переиспользовать из проекта в проект.
Я очень люблю логировать ход работы приложения, поэтому перенесу свою обёртку над логером logrus из другого проекта. Основная функция здесь Init, которая создает логер, папку logs и в ней файл all.log со всеми логами. Кроме файла логи будут выводиться в STDOUT. Также в пакете реализована поддержка логирования в разные файлы с разным уровнем логирования, но в текущем проекте мы это использовать не будем.
APIService будет работать на сокете. Создаём роутер, затем файл с сокетом и начинаем его слушать. Также мы хотим перехватывать от системы сигналы завершения работы. Например, если кто-то пошлёт приложению сигнал SIGHUP, приложение должно корректно завершиться, закрыв все текущие соединения и сессии. Хотел перехватывать все сигналы, но линтер предупреждает, что os.Kill и SIGSTOP перехватить не получится, поэтому их удаляем из этого списка.
Теперь давайте добавим сразу стандартный handler для метрик. Я его копирую в директорию pkg, далее добавляю в роутер. Все последующие роутеры будем добавлять так же.
Далее создаём точку входа в приложение. В директории cmd создаём директорию main, а в ней — файл app.go. В нём мы создаём функцию main, в которой инициализируем и создаём логер. Роутер создаём через ключевое слово defer, чтобы метод Init у роутера вызвался только тогда, когда завершится функция main. Таким образом можно выполнять очистку ресурсов, закрытие контекстов и отложенный запуск методов. Запускаем, проверяем логи и сокет, всё работает.
Но для разработки нам нужно запускать приложение на порту, а не на сокете. Поэтому давайте добавим запуск приложения на порту в наш роутер. Определять, как запускать приложение, мы будем с помощью конфига.
Создадим для приложения контекст. Сделаем его синглтоном при помощи механизма sync.Once. Пока что в нём будет только конфиг. Контекст в виде синглтона создаю исключительно в учебных целях, впоследствии он будет выпилен. В большинстве случаев синглтоны — необходимое зло, в нашем проекте они не нужны. Далее создаём конфиг. Это будет YAML-файл, который мы будем парсить в структуру.
В роутере мы вытаскиваем из контекста конфиг и на основании listen.type либо создаем сокет, либо вешаем приложение на порт. Код graceful shutdown выделяем в отдельный пакет и передаём на вход список сигналов и список интерфейсов io.Close, которые надо закрывать. Запускаем приложение и проверяем наш эндпоинт heartbeat. Всё работает. Давайте и конфиг сделаем синглтоном через механизм sync.Once, чтобы потом безболезненно удалить контекст, который создавался в учебных целях.
Теперь переходим к API. Создаём эндпоинты, полученные при анализе прототипов интерфейса. Тут важно отметить, что у нас все данные привязаны к пользователю. На первый взгляд, все ручки должны начинаться с пользователя и его идентификатора /api/users/:uuid. Но у нас будет авторизация, иначе любой пользователь сможет программно запросить заметки любого другого пользователя. Авторизацию можно сделать следующим образом: Basic Auth, Digest Auth, JSON Web Token, сессии и OAuth2. У всех способов есть свои плюсы и минусы. Для этого проекта мы возьмём JSON Web Token.
Работа с JSON Web Token
JSON Web Token (JWT) — это JSON-объект, который определён в открытом стандарте RFC 7519. Он считается одним из безопасных способов передачи информации между двумя участниками. Для его создания необходимо определить заголовок (header) с общей информацией по токену, полезные данные (payload), такие как id пользователя, его роль и т.д., а также подписи (signature).
JWT использует преимущества подхода цифровой подписи JWS (Signature) и кодирования JWE (Encrypting). Подпись не даёт кому-то подделать токен без информации о секретном ключе, а кодирование защищает от прочтения данных третьими лицами. Давайте разберёмся, как они могут нам помочь для аутентификации и авторизации пользователя.
Аутентификация — процедура проверки подлинности. Мы проверяем, есть ли пользователь с полученной связкой логин-пароль в нашей системе.
Авторизация — предоставление пользователю прав на выполнение определённых действий, а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.
Другими словами, аутентификация проверяет легальность пользователя. Пользователь становится авторизированным, если может выполнять разрешённые действия.
Важно понимать, что использование JWT не скрывает и не маскирует данные автоматически. Причина использования JWT — проверка, что отправленные данные были действительно отправлены авторизованным источником. Данные внутри JWT закодированы и подписаны, но не зашифрованы. Цель кодирования данных — преобразование структуры. Подписанные данные позволяют получателю данных проверить аутентификацию источника данных.
Реализация JWT в нашем APIService:
- Создаём директории middleware и jwt, а также файл jwt.go.
- Описываем кастомные UserClaims и сам middlware.
- Получаем заголовок Authorization, оттуда берём токен.
- Берём секрет из конфига.
- Создаём верификатор HMAC.
- Парсим и проверяем токен.
- Анмаршалим полученные данные в модель UserClaims.
- Проверяем, что токен валидный на текущий момент.
При любой ошибке отдаём ответ с кодом 401 Unauthorized. Если ошибок не было, в контекст сохраняем ID пользователя в параметр user_id, чтобы во всех хендлерах его можно было получить. Теперь надо этот токен сгенерировать. Это будет делать хендлер авторизации с методом POST и эндпоинтом /api/auth. Он получает входные данные в виде полей username и password, которые мы описываем отдельной структурой user. Здесь также будет взаимодействие с UserService, нам надо там искать пользователя по полученным данным. Если такой пользователь есть, то создаём для него UserClaims, в которых указываем все нужные для нас данные. Определяем время жизни токена при помощи переменной ExpiresAt — берём текущее время и добавляем 15 секунд. Билдим токен и отдаём в виде JSON в параметре token. Клиента к UserService у нас пока нет, поэтому делаем заглушку.
Добавим в хендлер с heartbeat еще один тестовый хендлер, чтобы проверить работу аутентификации. Пишем небольшой тест. Для этого используем инструмент sketch, встроенный в IDE. Делаем POST-запрос на /api/auth, получаем токен и подставляем его в следующий запрос. Получаем ответ от эндпоинта /api/heartbeat, по истечении 5 секунд мы начнём получать ошибку с кодом 401 Unauthorized.
Наш токен действителен очень ограниченное время. Сейчас это 15 секунд, а будет минут 30. Но этого всё равно мало. Когда токен протухнет, пользователю необходимо будет заново авторизовываться в системе. Это сделано для того, чтобы защитить пользовательские данные. Если злоумышленник украдет токен авторизации, который будет действовать очень большой промежуток времени или вообще бессрочно, то это будет провал.
Чтобы этого избежать, прикрутим refresh-токен. Он позволит пересоздать основной токен доступа без запроса данных авторизации пользователя. Такие токены живут очень долго или вообще бессрочно. После того как только старый JWT истекает мы больше не можем обратиться к API. Тогда отправляем refresh-токен. Нам приходит новая пара токена доступа и refresh-токена.
Хранить refresh-токены на сервере мы будем в кэше. В качестве реализации возьмём FreeCache. Я использую свою обёртку над кэшем из другого проекта, которая позволяет заменить реализацию FreeCache на любую другую, так как отдает интерфейс Repository с методами, которые никак не связаны с библиотекой.
Пока рассуждал про кэш, решил зарефакторить существующий код, чтобы было удобней прокидывать объекты без dependency injection и синглтонов. Обернул хендлеры и роутер в структуры. В хендлерах сделал интерфейс с методом Register, которые регистрируют его в роутере. Все объекты теперь инициализируются в main, весь роутер переехал в мейн. Старт приложения выделили в отдельную функцию также в main-файле. Теперь, если хендлеру нужен какой-то объект, я его просто буду добавлять в конструктор структуры хендлера, а инициализировать в main. Плюс появилась возможность прокидывать всем хендлерам свой логер. Это будет удобно когда надо будет добавлять поле trace_id от Zipkin в строчку лога.
Вернемся к refresh_token. Теперь при создании токена доступа создадим refresh_token и отдадим его вместе с основным. Сделаем обработку метода PUT для эндпоинта /api/auth, а в теле запроса будем ожидать параметр refresh_token, чтобы сгенерировать новую пару токена доступа и refresh-токена. Refresh-токен мы кладём в кэш в качестве ключа. Значением будет user_id, чтобы по нему можно было запросить данные пользователя у UserService и сгенерировать новый токен доступа. Refresh-токен одноразовый, поэтому сразу после получения токена из кэша удаляем его.
Описание API
Для описания нашего API будем использовать спецификацию OpenAPI 3.0 и Swagger — YAML-файл, который описывает все схемы данных и все эндпоинты. По нему очень легко ориентироваться, у него приятный интерфейс. Но описывать вручную всё очень муторно, поэтому лучше генерировать его кодом.
- Создаём эндпоинты /api/auth с методами POST и PUT для получения токена по юзернейму и паролю и по Refresh-токену соответственно.
- Добавляем схемы объектов Token и User.
- Создаём эндпоинты /api/users с методом POST для регистрации нового пользователя. Для него создаём схему CreateUser.
Понимаем, что забыли сделать хендлер для регистрации пользователя. Создаём метод Signup у хенлера Auth и структуру newUser со всеми полями для регистрации. Генерацию JWT выделяем в отдельный метод, чтобы можно было его вызывать как в Auth, так и в Signup-хендлерах. У нас всё еще нет UserService, поэтому проставляем TODO. Нам надо будет провалидировать полученные данные от пользователя и потом отправить их в UserService, чтобы он уже создал пользователя и ответил нам об успехе. Далее вызываем функцию создания пары токена доступа и refresh-токена и отдаём с кодом 201.
У нас есть подсказка в виде Swagger-файла. На его основе создаём все нужные хендлеры. Там, где вызов микросервисов, будем проставлять комментарий с TODO.
Создаём хендлер для категорий, определяем URL в константах. Далее создаём структуры. Опираемся на Swagger-файл, который создали ранее. Далее создаём сам хендлер и реализуем метод Register, который регистрирует его в роутере. Затем создаём методы с логикой работы и сразу пишем тест API на этот метод. Проверяем, находим ошибки в сваггере. Таким образом мы создаём все методы по работе с категориями: получение и создание.
Далее создаём таким же образом хендлер для заметок. Понимаем, что забыли методы частичного обновления и удаления как для заметок, так и для категорий. Дописываем их в Swagger и реализуем методы в коде. Также обязательно тестируем Swagger в онлайн-редакторе.
Здесь надо обратить внимание на то, что методы создания сущности возвращают код ответа 201 и заголовок Location, в котором находится URL для получения сущности. Оттуда можно вытащить идентификатор созданной сущности.
В третьей части мы познакомимся с графовой базой данных Neo4j, а также будем работать над микросервисами CategoryService и APIService.
Привет всем. Несмотря на то, что первый пост закидали минусами я (а точнее уже мы не) не сдаёмся.
Ищем junior frontend разработчика, у которого есть желание написать своё web приложение с целью добавления в свой репозиторий чего-то приличного. Пока что в обсуждении мы остановились на сервисе онлайн заказа услуги (сама услуга не важна в данный момент и может быть как заказом грузчиков на выезд, заказом доставки еды и тп).
Архитектура — стандартный MVC. Backend на java (Spring boot, mvc, data, security), БД postgre. На фронт передаем json. Хотелось бы чтобы фронт работал с ajax запросами, остальное на ваш вкус и цвет.
Функционал. Регистрация/авторизация, вывод услуг и их сортировка по параметрам, заказ услуги, уведомление на email о заказе.
Итого, если ты front junior, учишь js и хочешь пополнить своё резюме небольшим проектом добро пожаловать в телеграм (в комментах).
Нас уже трое: devops (Харьков) и 2 java (Минск и Питер). Встретились украинец, белорус и русский:)
UPD после первых комментариев. Все понимают что это не работа на которой вам платят деньги. Никто не ожидает от вас стабильного присутствия в назначенное время, вся работа по мере своих сил возможностей и интереса.
Тем не менее, Горячие Источники стали курортом. Здесь можно было собрать уникальные ингридиенты для кулинарии, а воды источников обладали целительной силой.
Постоянными клиентами Горячих Источников были гномы, для которых запах недр земли не был настолько раздражающим.
Здесь можно было на некоторое время забыть о королях и их войнах, о претензиях орков и гномов на снежный город Шутгарт,
о процветании и банкротстве, об интригах торговых гильдий Серебряных Весов и Золотого Колеса (45), а также очередных выборах первого старейшины, которым долгие годы оставался Локирин Каменщик — глава гильдии Бронзового Ключа (46).
Сила Мафр даровала гномам долгую жизнь, короче эльфийской, но намного длиннее, чем у людей. Самому старому гному удалось дожить до тысячи лет, в то время, когда эльфы жили тысячилетиями (47). И этой жизнью гномы научились дорожить...
Ледяной ветер прерывает тёплые воспоминания о прошлом. Солнце уже давно прошло свою самую высокую точку на небосводе и начало устало клониться к горизонту.
Начинает темнеть... Просто немыслимо, сколько всего похоронил снег! Неужели даже горячая лава вулкана не смогла остановить надвигающуюся катастрофу?..
Однажды бог хаоса Гран Каин вместе со своей младшей дочерью Евой спустились на землю, чтобы исполнить несколько важных дел. Пока бог оставался в своей сущности, он становился все несдержанней день ото дня.
До него дошли слухи о том, что принцесса Фелиция была изгнана Империей, а ее родственники обвинены в использовании темной магии. Фелиция, сопровождаемая личной охраной — рыцарями Канна, отправилась в зимний лабиринт на территорию города Шутгарт и осталась там, увеличивая свои магические способности, чтобы отплатить повинным в ее изгнании и гонении всей ее семьи (48).
Принцесса обладала не только необычайной красотой, но и острым умом, а также магическим талантом.
Поэтому для её обучения была приглашена эльфийская чародейка, магистр Сирра, называвшая юную принцессу ласково "Лиция". В обязанности Сирры входило также управление дворцом.
Юная Фелиция была поглощена обучением и жаждой новых знаний.
Гран Каин понял, что она может пригодиться ему. Именно Фелиция поможет богу исполнить задуманное... Первый Бог Тьмы, использовав части Уставшей Души, Порочной Воды (именно те ингридиенты, использовав которые, Бог Тьмы создал человечество) и часть своей собственной магической силы, создал Дух Воды, который сконцентрировал в себе Свет Бездны. Духа он запечатал в кристальный шар.
Богу прекрасно было известно, что Фелиция не возьмет шар, не познав всю его силу и мощь. Тогда всё пойдёт по плану... Гран Каин, обернувшись путешествующим волшебником, отправился на встречу к Фелиции в замок, расположенный на острове севернее окраин Зимнего Лабиринта.
В тот злополучный день к дворцу пришел мудрец, назвавший себя Саяном (49). Он сказал, что нашел кристалл, который содержал в себе огромную мощь холода, и искал того, кто мог овладеть его энергией. Фелиция, всегда прилежная в своих исследованиях и пытавшаяся всегда проявить себя, охотно согласилась (50).
В тот момент, когда Фелиция и Саян встретились, кристалл разрушился, и его энергия омылась над Фелицией (51).
Последствия были ужасными и их ещё можно было избежать. Но принцесса спрятала осколки кристалла и сохранила случившееся в тайне. Вскоре после этого Саян исчез, а Фелиция начала меняться. Она начала настаивать на том, чтобы другие в королевском дворе называли её Фрейей, и становилась всё более угрюмой и одержимой.
Прошла неделя, и слуга назвал ее Фелицией по ошибке. Этого оказалось достаточно, чтобы вызвать гнев Фрейи. Он был обращён в лёд, а за ним — и все остальные. Так началось царствование Ледяной Королевы.
(45. — кв. "Уничтожение бандитов")
(46. — кв. "Испытание мастера")
(47. — администратор склада Вилфорд, деревня Говорящего острова)
(48. — здесь и далее за основу взята центральная цепочка хроник Фрея, начинающаяся с кв. "Обратная сторона правды", дополненная историей с хроник ГоД и внешних источников, часто повторяющихся и, предположительно, — официальных.
http://lineage2ru.livejournal.com/537.html
У квеста есть расхождения с историей Фреи в Таинственной таверне более поздних хроник, в частности — имя Фелиция изменено на Мелисса)
(49. — в разных источниках и хрониках — Сеан или Сиан)
(50. — мотивация Фелиции по квесту — любопытство, в то время, когда по внешним источникам — месть)
(51. — по версии квеста, Фелиция разбила кристалл по собственной глупости и превращалась во Фрею постепенно, по второй версии, она отказала Гран Каину принять его и он разбил кристалл сам, замок и все кто были в нём обратились моментально)
Выспаться, провести генеральную уборку, посмотреть все новые сериалы и позаниматься спортом. Потом расстроиться, что время прошло зря. Есть альтернатива: сесть за руль и махнуть в путешествие. Как минимум, его вы всегда будете вспоминать с улыбкой. Собрали несколько нестандартных маршрутов.
Можно тестировать API различных сервисов.
Примечательно, что аудио контент можно формировать прямо из приложения с помощью встроенного рекордера и результат передавать в встроенный аудио проигрыватель, что удобно для тестирования сервисов распознавания и синтеза речи.
В заголовках и параметрах можно использовать функции NewGuid(), GetAPi() - для получения результата другого API.
Например, получаем токен - ApiCognitiveMicrosoftStsToken и передаем в заголовок "Authorization" с помощью функции - "Bearer GetApi('ApiCognitiveMicrosoftStsToken')"
Так можно тестировать API ботов, сервисов Google, Microsoft, Yandex и т.д.
Скачать можно тут https://www.microsoft.com/ru-ru/store/p/neoresthelper/9nr7pl...