Esi eve online что это
Обновлено: 25.06.2024
Esi eve online что это
Примечание: данный девблог в первую очередь предназначен для сторонних разработчиков и технически грамотных капсулёров. Если вы хотите пропустить жаргон, прокрутите вниз где найдёте TL;DR
Предыстория
В тот момент когда XML API был впервые опубликован, это было прорывом. До этого момента ни одна видеоигра не предоставляла такого доступа к своим данным, что позволило игрокам сделать удивительные вещи. EVEMon и EFT это легендарные инструменты которые поддерживают EVE годами, и они присоединились к множеству новаторских и действенных решений созданных игроками основываясь на XML API. Но XML API имеет предел, возможность использования только определенных данных, только чтение данных и порой медленное реагирование на внутриигровые события. Серьёзно, протоколирование XML API это тихий ужас, постоянные отставания от реальной версии игры и по сути никакого развития.
И так мы представляем CREST, и это тоже прорыв. Он использует, более понятный формат данных, упрощенный интерфейс и быстрый доступ к оперативному моделированию данных. В конце концов, это открывает путь для записи конечных точек, которое используется повсюду, но впервые в игровой индустрии. Некоторые работы созданные на базе новых возможностей CREST просто ошеломляющие, и мы постоянно слышим о новых и инновационных идеях очень многие из которых могут быть реализованы с использованием новых мощных возможностей CREST.
Также в идеале CREST планируется сделать само индексируемым. Комбинация автоматически генерируемых вызываемых опций и примеров связанных с корневой структурой API обеспечивает фактически полную само индексацию API. Это привело к определенным успехам, и сбор данных CREST API это, безусловно, хороший способ для пользователей изучить его. Однако, выявлены и определенные проблемы. Огромная часть данных не может быть индексированы пока не выполнены определённые игровые условия,такие как правильное определение корпоративных ролей или определение владельца цитадели, и не все ресурсы корректно привязываются. Это довольно трудно объяснить почему у вас нету доступа к определенным вещам. Разработчики CREST до сих пор ссылаются на сторонние протоколы для полного описания API. Это была смелая попытка, но этого явно недостаточно.
CCP всегда был в авангарде API разработок в игровой индустрии, и мы не собираемся останавливаться на достигнутом и почивать на лаврах. Мы видели как хорошо было принято создание CREST и XML API, мы учли критические ошибки, и сейчас наступило время модернизации. Читать ниже…
Тем временем, в целом в игровой индустрии.
За последнии несколько лет, индустрия програмного обеспечения занималась разработкой различных и рассмотрением архитектуры различных API. Сначала из все этого хаоса возникла стандартная схема JSON, а потом уже из неё спецификация Swagger. Это основной концепт ESI, давайте послушаем что сам swagger говорит о себе:
Swagger™это программа используемая для описания и записи RESTful APIs. Спецификация swagger определяет набор файлов требуемых для описания определенного API. Данные файлы могут быть использованы системой Swagger-UI для отображения API и Swagger-Codegen для создания клиентской части на различных языках. Дополнительные утилиты также могут получать преимущество от полученных в результате файлов, например инструменты тестирования.
Swagger это широко применяемый стандарт описания API, и поддерживается несколькими авторитетными компаниями, что даёт определённую уверенность в его долговечности и поддержке клиентских библиотек, пользовательского интерфейса и прочих инструментов. Выбор спецификации Swagger (сейчас известной как OpenAPI) избавляет нас от лишней работы, и дает нам четкий ориентир для построения в отличии любой пользовательской конфигурации.
Это тот фундамент который мы выбрали для построения EVE Swagger Interface, тот каркас объединяющий части спецификаций из многочисленных служб Kubernetes в единый механизм, который в тоже время занимается маршрутизацией, аутентификацией, вводом/выводом данных, и многими другими функциями.
EVE Swagger Interface (кратко ESI, произносится «изи») использует Flask и Python 3.4+ внутренне, а возможность использовать обобщённые настройки достаточна для поддержки любых внешних (или неавторизованных), многопользовательских API работающих в кластерах Kubernetes.
Чем является ESI для нас?
В течении последних нескольких месяцев, мы использовали и развивали платформу ESI для построения новых API с нуля. ESI API это ESTful, SSO авторизация, первичное индексирование, совместимость с основными шаблонами, горизонтально масштабируемые, читаемо/записываемые API. Всё это позволило вернуть мобильное приложение EVE и запустило кластер Kubernetes в Google Cloud (Kubernetes is невероятен btw). Что чёрт возьми всё это значит?
Совместимость с основными шаблонами означает что мы использовали основные инструменты индустрии разработки. Мы постарались добавить по минимуму специальных инструментов только там где без этого не обойтись, в остальном же мы старались заменять кастомные вещи на готовые стандартные опенсорс решения когда это было возможно. Ещё никогда EVE API не был так лёгок в обслуживании и масштабировании, что открывает недоступные ранее возможности. Небольшие патчи могут отправляться с компьютера разработчика к его приложению в течении минут, и если это необходимо все изменения могут быть с практически нулевой задержкой откатаны назад в любом направлении.
Горизонтальное масштабирование — это изящное решение которое мы позаимствовали у Kubernetes. Так как все ESI коды которым не требуется быть специально запущенными на нашем сервере Транквилити, а также не требуется запуска на Google Cloud, мы можем управлять подключением новых ESI контейнеров на каждый результирующий базис которому это необходимо, и выключением этих компонентов когда они больше не нужны.
Так что насчёт старых XML API и CREST?
Ещё рано паниковать. Мы пришли сюда не для того чтобы объявить о том что мы незамедлительно уничтожим все ваши приложения и вам необходимо немедленно переписать весь код, но мы считаем нужным обсудить приведение кода в порядок и его фрагментирование. Поддержка тройки API с похожим , но не пересекающимся функционалом увеличивает техническую сложность создания рабочих EVE API моделей, и это забирает время у тех. группы которые они бы потратили на разработку новых инструментов и обслуживание нового инструментария. Всё это уменьшает гибкость и увеличивает нестабильность, и это не есть хорошо в плане долгосрочного развития.
Как только мы воссоздадим все текущие возможности CREST и XML API в ESI, мы сразу же закроем оба этих сервиса. Мы запланировали 18 месяцев от релиза этого блога до достижения ESI требуемого функционала и мы будем работать с разработчика приложений для апгрейда их продуктов. Удаление необходимости использования XML API наша главная цель. Мы будем следить за использования XML API и CREST для идентификации и помощи разработчикам сторонних программ в их переходе на новую систему.
Это будет аккуратный и планомерный уход от старой системы. Первым шагом этого процесса является то что с момента выхода этого блога, CREST и XML API официально находятся только в режиме поддержания в рабочем состоянии.
Мы будем продолжать выпускать обновления для защиты данных и исправления критических ошибок к ним, но все новые запросы будут исполнятся ESI API.
Ранний доступ
В течении последнего месяца мы плотно работали с несколькими активными членами сообщества разработчиков сторонних сервисов для EVE, включая:
Мы взаимодействовали с этими командами , так же как и с фокус группами , для получения отзывов на раннии этапы развития проекта и некоторые первоначальные проектные решения. Ниже вы можете увидеть что они могут сейчас сказать о своих впечатлениях:
Введение ESI, как нового API, довольно близко к тому как работает CREST, поэтому переход на новую систему должен пройти довольно таки легко. Также это решает проблему главного “пугала” разработчиков API приложений для EVE. Нехватки документации и примеров. Использование Swagger облегчит работу с API, и уберет проблему некоторых несоответствий из списка проблем разработчиков. Наконец открыта возможность отправлять EVEMail, так же как и получать их, это большой прорыв, что допускает возможность создавать некоторые автоматизированные сервисы , что раньше было невозможно.
- Steve Ronuken
EVE Swagger Interface объединяет возможности XML AP с инновациями CREST в то время как введение в документацию является официальной фичей. CREST’о подобные системы позволили людям делать замечательные вещи с динамическими языками (имеются в виду языки программирования , я так думаю - прим. пер.), ESI ближе тем из нас кто любит использовать статические языки; предоставляя более строгий разрешенный интерфейс и улучшая пользовательские аспекты CREST. Я верю что этот проект прекрасная возможность последующего улучшения CREST, модернизации XML API, и разработка приложений для EVE станет более доступна для новичков.
- Lucia Denniard
Новый API приходит в EVE, его зовут ESI. Он основывается на OpenAPI Specification, полностью документирован и сделает вашу жизнь проще если вы захотите сделать приложение для EVE Online. Он будет вводиться в течение нескольких месяцев, и уже сейчас обрабатывает до 4,5 миллионов запросов в день.
Если вы не являетесь разработчиком приложений , то в течении следующего года или двух вы с можете заметить что приложения которые вы используете начинают уходить от API ключей и переходить на EVE SSO. Это дает преимущества в безопасности, и уменьшает сложности авторизации в приложениях.
В славное будущее!
PS: если вас всё ещё интересует дизайн ESI, загляните в следующий блог Introducing the ESI API.
Перевод © Deornot
[девблог]Представляем ESI - Новый API для EVE ONLINE
Clone Grade Zeta
- EVE Ingame: Deornot
- Corp: NPC
- Client: Eng
ПРЕДСТАВЛЯЕМ ESI - НОВЫЙ API ДЛЯ EVE ONLINE
Примечание: данный девблог в первую очередь предназначен для сторонних разработчиков и технически грамотных капсулёров. Если вы хотите пропустить жаргон, прокрутите вниз где найдёте TL;DR
Предыстория
В тот момент когда XML API был впервые опубликован, это было прорывом. До этого момента ни одна видеоигра не предоставляла такого доступа к своим данным, что позволило игрокам сделать удивительные вещи. EVEMon и EFT это легендарные инструменты которые поддерживают EVE годами, и они присоединились к множеству новаторских и действенных решений созданных игроками основываясь на XML API. Но XML API имеет предел, возможность использования только определенных данных, только чтение данных и порой медленное реагирование на внутриигровые события. Серьёзно, протоколирование XML API это тихий ужас, постоянные отставания от реальной версии игры и по сути никакого развития.
И так мы представляем CREST, и это тоже прорыв. Он использует, более понятный формат данных, упрощенный интерфейс и быстрый доступ к оперативному моделированию данных. В конце концов, это открывает путь для записи конечных точек, которое используется повсюду, но впервые в игровой индустрии. Некоторые работы созданные на базе новых возможностей CREST просто ошеломляющие, и мы постоянно слышим о новых и инновационных идеях очень многие из которых могут быть реализованы с использованием новых мощных возможностей CREST.
Также в идеале CREST планируется сделать само индексируемым. Комбинация автоматически генерируемых вызываемых опций и примеров связанных с корневой структурой API обеспечивает фактически полную само индексацию API. Это привело к определенным успехам, и сбор данных CREST API это, безусловно, хороший способ для пользователей изучить его. Однако, выявлены и определенные проблемы. Огромная часть данных не может быть индексированы пока не выполнены определённые игровые условия,такие как правильное определение корпоративных ролей или определение владельца цитадели, и не все ресурсы корректно привязываются. Это довольно трудно объяснить почему у вас нету доступа к определенным вещам. Разработчики CREST до сих пор ссылаются на сторонние протоколы для полного описания API. Это была смелая попытка, но этого явно недостаточно.
CCP всегда был в авангарде API разработок в игровой индустрии, и мы не собираемся останавливаться на достигнутом и почивать на лаврах. Мы видели как хорошо было принято создание CREST и XML API, мы учли критические ошибки, и сейчас наступило время модернизации. Читать ниже…
Тем временем, в целом в игровой индустрии.
За последнии несколько лет, индустрия програмного обеспечения занималась разработкой различных и рассмотрением архитектуры различных API. Сначала из все этого хаоса возникла стандартная схема JSON, а потом уже из неё спецификация Swagger. Это основной концепт ESI, давайте послушаем что сам swagger говорит о себе:
Swagger™это программа используемая для описания и записи RESTful APIs.
Спецификация swagger определяет набор файлов требуемых для описания определенного API. Данные файлы могут быть использованы системой Swagger-UI для отображения API и Swagger-Codegen для создания клиентской части на различных языках. Дополнительные утилиты также могут получать преимущество от полученных в результате файлов, например инструменты тестирования.
Swagger это широко применяемый стандарт описания API, и поддерживается несколькими авторитетными компаниями, что даёт определённую уверенность в его долговечности и поддержке клиентских библиотек, пользовательского интерфейса и прочих инструментов. Выбор спецификации Swagger (сейчас известной как OpenAPI) избавляет нас от лишней работы, и дает нам четкий ориентир для построения в отличии любой пользовательской конфигурации.
Это тот фундамент который мы выбрали для построения EVE Swagger Interface, тот каркас объединяющий части спецификаций из многочисленных служб Kubernetes в единый механизм, который в тоже время занимается маршрутизацией, аутентификацией, вводом/выводом данных, и многими другими функциями.
EVE Swagger Interface (кратко ESI, произносится "изи") использует Flask и Python 3.4+ внутренне, а возможность использовать обобщённые настройки достаточна для поддержки любых внешних (или неавторизованных), многопользовательских API работающих в кластерах Kubernetes.
Чем является ESI для нас?
В течении последних нескольких месяцев, мы использовали и развивали платформу ESI для построения новых API с нуля. ESI API это ESTful, SSO авторизация, первичное индексирование, совместимость с основными шаблонами, горизонтально масштабируемые, читаемо/записываемые API. Всё это позволило вернуть мобильное приложение EVE и запустило кластер Kubernetes в Google Cloud (Kubernetes is невероятен btw). Что чёрт возьми всё это значит?
Первичное индексирование означает что внутри системы мы использовали инструкции Swagger’а для генерации наших APIs. Первый шаг для создания или обновления конечного результата какого-либо действия это создание или обновления соответствующей инструкции, что определяет всю нашу внутреннюю структуру данных для обработки конечного результата, и это значит что протоколы данных всегда обновлены потому что они интегрированы с основной частью кода конечного результата. Don't look now, but we might have solved this documentation gremlin. В дополнение к всему инструменты Swagger позволяют сторонним разработчикам использовать свой код для создания интерфейса для ESI API на том языке который они выберут. Огромный кусок времени разработчика который раньше тратился на построение интерфейса для CREST и XML API теперь освобожден от этой шаблонной работы. (мы заменили вас на роботов, простите.)
Совместимость с основными шаблонами означает что мы использовали основные инструменты индустрии разработки. Мы постарались добавить по минимуму специальных инструментов только там где без этого не обойтись, в остальном же мы старались заменять кастомные вещи на готовые стандартные опенсорс решения когда это было возможно. Ещё никогда EVE API не был так лёгок в обслуживании и масштабировании, что открывает недоступные ранее возможности. Небольшие патчи могут отправляться с компьютера разработчика к его приложению в течении минут, и если это необходимо все изменения могут быть с практически нулевой задержкой откатаны назад в любом направлении.
Горизонтальное масштабирование - это изящное решение которое мы позаимствовали у Kubernetes. Так как все ESI коды которым не требуется быть специально запущенными на нашем сервере Транквилити, а также не требуется запуска на Google Cloud, мы можем управлять подключением новых ESI контейнеров на каждый результирующий базис которому это необходимо, и выключением этих компонентов когда они больше не нужны.
Так что насчёт старых XML API и CREST?
Ещё рано паниковать. Мы пришли сюда не для того чтобы объявить о том что мы незамедлительно уничтожим все ваши приложения и вам необходимо немедленно переписать весь код, но мы считаем нужным обсудить приведение кода в порядок и его фрагментирование. Поддержка тройки API с похожим , но не пересекающимся функционалом увеличивает техническую сложность создания рабочих EVE API моделей, и это забирает время у тех. группы которые они бы потратили на разработку новых инструментов и обслуживание нового инструментария. Всё это уменьшает гибкость и увеличивает нестабильность, и это не есть хорошо в плане долгосрочного развития.
Как только мы воссоздадим все текущие возможности CREST и XML API в ESI, мы сразу же закроем оба этих сервиса. Мы запланировали 18 месяцев от релиза этого блога до достижения ESI требуемого функционала и мы будем работать с разработчика приложений для апгрейда их продуктов. Удаление необходимости использования XML API наша главная цель. Мы будем следить за использования XML API и CREST для идентификации и помощи разработчикам сторонних программ в их переходе на новую систему.
Это будет аккуратный и планомерный уход от старой системы. Первым шагом этого процесса является то что с момента выхода этого блога, CREST и XML API официально находятся только в режиме поддержания в рабочем состоянии.
Мы будем продолжать выпускать обновления для защиты данных и исправления критических ошибок к ним, но все новые запросы будут исполнятся ESI API.
Ранний доступ
В течении последнего месяца мы плотно работали с несколькими активными членами сообщества разработчиков сторонних сервисов для EVE, включая:
Мы взаимодействовали с этими командами , так же как и с фокус группами , для получения отзывов на раннии этапы развития проекта и некоторые первоначальные проектные решения. Ниже вы можете увидеть что они могут сейчас сказать о своих впечатлениях:
Введение ESI, как нового API, довольно близко к тому как работает CREST, поэтому переход на новую систему должен пройти довольно таки легко. Также это решает проблему главного “пугала” разработчиков API приложений для EVE. Нехватки документации и примеров. Использование Swagger облегчит работу с API, и уберет проблему некоторых несоответствий из списка проблем разработчиков. Наконец открыта возможность отправлять EVEMail, так же как и получать их, это большой прорыв, что допускает возможность создавать некоторые автоматизированные сервисы , что раньше было невозможно.
EVE Swagger Interface объединяет возможности XML AP с инновациями CREST в то время как введение в документацию является официальной фичей. CREST’о подобные системы позволили людям делать замечательные вещи с динамическими языками (имеются в виду языки программирования , я так думаю - прим. пер.), ESI ближе тем из нас кто любит использовать статические языки; предоставляя более строгий разрешенный интерфейс и улучшая пользовательские аспекты CREST. Я верю что этот проект прекрасная возможность последующего улучшения CREST, модернизации XML API, и разработка приложений для EVE станет более доступна для новичков.
TL;DR
Новый API приходит в EVE, его зовут ESI. Он основывается на OpenAPI Specification, полностью документирован и сделает вашу жизнь проще если вы захотите сделать приложение для EVE Online. Он будет вводиться в течение нескольких месяцев, и уже сейчас обрабатывает до 4,5 миллионов запросов в день.
Если вы не являетесь разработчиком приложений , то в течении следующего года или двух вы с можете заметить что приложения которые вы используете начинают уходить от API ключей и переходить на EVE SSO. Это дает преимущества в безопасности, и уменьшает сложности авторизации в приложениях.
В славное будущее!
PS: если вас всё ещё интересует дезайн ESI, загляните в следующий блог Introducing the ESI API.
Кстати товарищи кто разбирается в предмете смело указывайте на ошибки. Поправлю.
"Я не бюро добрых дел, а ведьма с бизнесом" (с)
Esi eve online что это
Это дополнение к гайду по evemon
Первым делом для работы с ивмон нам надо создать client ID.
За аккаунт не переживаем, логин/пароль ивмон не сохраняет, а приложение по сути лежит у сср в кармане и мы получаем доступ к нему по требованию.
Придумываем название и описание (насколько больная фантазия позволяет, русский работает через раз, могут вылезти потом . ). Выбираем Authentication & API Access
Набираем “esi” для удобной фильтрации (очень много там всего). Это нам облегчит немного задачу, теперь усердно начинаем тыкать мышкой по списку пока ВСЕ доступы из левого окошка не перенесем в правое. Просто тыкаем мышкой и оно переносится.
Тыкаем. Мы кулхацкеры!
В нем нас интересует APPLICATION SETTINGS, страницу пока не закрываем и запускаем ивмон.
Разрабочик советуют сбросить настройки если использовалась крайне древняя версия (сохраняем планы на всякий и идем в File > Reset Settings, сбрасываем)
Нажимаем Tools - Options - Network видим знакомые на басурманском слова, возвращаемся к странице где открыто наше приложение и копируем/вставляем в ивмон, нажимаем ок. Видим пустое окно внезапно.
Нажимаем File > Add Character и видим окно с импортом (если ничего не видно значит допустили ошибки при создании/копировании), нажимаем и попадаем на страницу уже с нашими пилотами. Выбираем нужного, катимся в самый низ страницы, даем доступ.
Возможно с первого раза не заработает, информации в ивмон не будет. Не пугаемся, судя по форумам еси подключается/работает не так быстро как апи и по этому может заработать минут через 5. На всякий случай можете сбросить еще раз настройки и вбить информацию с сайта еще раз. Примерно часов за 5 запущенной программы я трижды получал ошибки о загрузке очереди скилов, валлет так и не загрузился. Спишем это на новую версию и обкатку
Разработчики подготовили большой техноблог про улучшение серверной архитектуры игры
В прошлом месяце команда CCP Games совершила прорыв в основах работы серверов MMORPG EVE Online, который ознаменует начало новой эпохи. Студии удалось внедрить современные технологии, позволяющие не только снизить нагрузку, но и открыть огромные возможности для улучшения вселенной Нового Эдема.
Последний раз сетевой уровень кардинально изменялся в 2011 году, когда компания CCP представила реализацию IOCP под названием CarbonIO, которая в конечном итоге стала основой печально известного замедления времени. Позже разработчики приступили к созданию чернового варианта Project Sanguine для решения проблем среды CarbonIO. Каждая оптимизация в EVE Online сводится к тщательному согласованию с Python Global Interpreter Lock (GIL). Просто Python может делать только одну вещь за раз. Принятие EVE Stackless Python, реализация IOCP через StacklessIO, затем CarbonIO и совместное проектирование с учетом замедления времени - все это поддерживает невероятную иллюзию о том, что Новый Эдем живой. Но что, если бы GIL не приходилось использовать для каждой возникающей идеи? Как можно извлечь выгоду из стремительного роста числа ядер в отрасли по сравнению с тактовой частотой отдельных процессоров?
В этом отношении было проведено множество экспериментов, имеющих непосредственное отношение к Project Sanguine, наиболее публичным из которых является EVE: Aether Wars. Цель заключалась не в том, чтобы коренным образом изменить модель коммуникации в EVE Online, а вместо этого изменить симуляционную модель. Project Sanguine же сконцентрировался на решении скучных элементов, которые представляют собой набор функций EVE. Симуляция почти 9 000 игроков в одном пространстве могла бы быть быстрее, если бы Новый Эдем не занимался обслуживанием огромного количества других вещей. Таким образом, Project Sanguine преследовал две цели: обойти GIL и создать условия для новых возможностей.
Теперь Новый Эдем может обрабатывать значительно больше данных. Когда началось создание ESI, CCP Games приступили к внедрению большего количества облачных технологий, таких как Kubernetes. По мере того, как стала очевидной потребность в простых примитивах синхронизации для обработки этой информации, был сделан большой шаг в сторону языка Go. Со временем эти технологии накапливались в отдельную экосистему и началась работа по созданию функций, позволяющих использовать преимущества новой способности работать с Новым Эдемом в соответствии с современными стандартами. Многие из них уже доступны игрокам.
До выпуска планов навыков каждая функция передавала данные на сервер через CarbonIO. Теперь это работает иначе, поскольку операции плана навыков не только передаются через gRPC, но и вовсе не взаимодействуют с Tranquility или его базами данных.
Почему так важен обход Tranquility и базы данных? Чтобы понять это, необходимо поговорить о неудачах. Часть пути привела к появлению множества новых техник и инструментов, с помощью которых можно увидеть Новый Эдем. Одна из концепций - распределенная трассировка с использованием новой любимой игрушки: Honeycomb.io. Вооружившись всеми новыми инструментами стало ясно, что именно происходит с планами навыков, когда они были запущены на основном сервере:
Несмотря на существование множества возможностей для улучшения в целом с производительностью все было в порядке:
Но уже на следующее утро ситуация начала выходить из под контроля:
Одна из самых сильных сторон новой экосистемы - отсутствие простоев. Чтобы спасти механику планирования навыков, не нужно перезагружать сервер. Также нету необходимости выпускать патч для сервера или клиента игры. Таким образом Project Sanguine эволюционировал в новую технологическую платформу под названием EVE: Quasar. Не зря разработчики называли текущий квадрант Gateway, поскольку он предвещает прямое использование шлюзов gRPC.
Команда CCP продолжит решать проблему устаревших сервисов путем развития Quasar и оптимизации древних систем, ускоряя их работу. Для обычных игроков это означает появление новых мощных функций для разных частей EVE Online. Разработчики также думают о публикации данных симуляции через Quasar, но для этого потребуется какое-то время.
Читайте также: