💬 Для Dapps отсутствие API означает отсутствие децентрализации

Для Dapps отсутствие API означает отсутствие децентрализации

Что касается децентрализованных приложений, то цель любой платформы — достичь настоящей децентрализации. Это намного, намного сложнее, чем кажется, и даже самым амбициозным криптоплатформам требуется основательная дорожная карта, значительные усилия и немного удачи, чтобы их платформа была достаточно диверсифицирована, чтобы передать бразды правления своему сообществу.

Однако децентрализованные приложения — это не острова. Независимо от цели Dapp, будь то DEX, торговая площадка или игра, для работы оно подключается к ряду других источников информации. Хотя это часто упускается из виду, если Dapp должен получить доступ к информации из централизованного источника, используя интерфейс, управляемый и контролируемый этим источником, он теряет свою децентрализацию. Вместо этого у него есть слабое звено в децентрализованной сети, которая теперь представляет собой цепочку с единой точкой отказа.

Чтобы природа децентрализованной экосистемы работала, должно быть много различных двухточечных интерфейсов, предотвращающих ошибку единой точки отказа, а также риски подделки данных, медленное время передачи и многие другие проблемы. Хорошая новость заключается в том, что технологическое сообщество создало идеальный инструмент для поддержки децентрализованной экосистемы: API. Давайте углубимся, чтобы увидеть, как работают API, почему именно интерфейс API так важен для Dapps, что могут сделать новые платформы, чтобы они опережали кривую разработки, и как некоторые платформы, такие как Bware Labs и CoinGecko, определили приоритеты разработки API. для своих пользователей.

Основы API

Первый интерфейс прикладного программирования, или API, был запущен в феврале 2000 года и предназначался для использования в качестве "Интернета как услуги". С тех пор API-интерфейсы стали предпочтительными межсоединениями информационной экосистемы. У большинства компаний нет основной стратегии и видения своих API как взаимосвязанного ландшафта. Даже для более простых предприятий это может быть фатальным недостатком. В сочетании с непредвиденными трудностями, такими как глобальная пандемия, невозможность создавать API и управлять ими может помешать предприятиям адаптироваться и выжить. С другой стороны, те предприятия, которые активно следовали стратегии своего API-ландшафта — например, рестораны, которым внезапно пришлось работать по бизнес-модели «удаленный заказ и доставка», — не только пережили многочисленные остановки, но процветали и даже росли в посреди этого убийцы индустрии.

Но что такое API? Самый простой метапер. Вы выбираете, кто является официантом в ресторане. Вы, как клиент, резервируете столик, просматриваете меню, и, когда вы готовы, подходит официант, чтобы взять ваш ордхат из меню, возможно, попросив небольшие изменения в том, что есть в меню. Официант примет ваш заказ (а если разрешены запрошенные корректировки, то и эти) и передаст его на кухню. Кухня готовит вашу еду, вы наслаждаетесь ею, а затем платите оговоренную цену. Теперь сравните это с информацией. Вы, пользователь (через платформу или интерфейс), хотели бы «заказать» конкретную информацию из источника данных; скажем, текущая цена токена с DEX. Для этого ваша платформа будет взаимодействовать с API DEX, предназначенным для предоставления этой информации. API — это ваш цифровой официант, через него вы запрашиваете свой заказ. Он проходит за брандмауэром (на кухню), просит систему (повара) подготовить ваши данные, а затем доставляет их вам. Если услуга была платной, вы оплачиваете чек.

Отличная метафора, верно? И это работает, если вы думаете о том, что может пойти не так. Ваша первая реакция может состоять в том, чтобы смотреть на официанта как на дополнительный шаг в процессе, тратя время и ресурсы. Но что, если бы ресторан позволил своим гостям свободно бродить по кухне и напрямую заказывать еду. Это создаст скопление людей, кто-то неизбежно опустит свою грязную руку в миску с едой, а шансы того, что кто-то украдет несколько кусочков отборных стейков, резко возрастут. Это кошмарный сценарий, и он закроет ресторан. Мы предоставим вам сделать подключение к примеру данных: чистый хаос, узкие места в обслуживании, нарушения безопасности и, возможно, пожар к концу дня.

API идеально подходят для Dapps

Теперь, когда вы знаете, что такое децентрализованные приложения, вы можете увидеть, как понятные и упорядоченные стандарты могут обеспечить эффективное взаимодействие как для платформ, так и для их пользователей. В дополнение к обеспечению безопасных коридоров для данных, API-интерфейсы создают простые в использовании прямые соединения в одноранговой манере. Нет необходимости в централизованной архитектуре с API. Любая организация может выбрать создание API, к которому другие организации или клиенты могут подключаться и обмениваться определенными данными. Без этой архитектуры полностью децентрализованное децентрализованное приложение полностью парализовано централизованным узким местом потока данных. Дело в том, что Dapps на основе блокчейна почти всегда требуют данные из других источников. Сразу создание стратегии на основе API позволяет сделать это быстрее и надежнее. И эти другие источники, вероятно, также развиваются, поэтому прямое соединение без API не будет работать, как только кто-то изменит переменную или имя файла на своей стороне. API-интерфейсы ориентированы на внешний мир, поэтому запрашивающей стороне не нужно понимать внутреннюю работу источника данных или платформы, с которой они взаимодействуют. Все, что им нужно знать, — это ключевые элементы API.

Стратегии надежной разработки децентрализованных приложений

Как начать работу с платформой? Для большинства платформ полезно иметь в команде кого-то, кто уже имеет опыт разработки API. Но для децентрализованных платформ взаимодействие с API означает доступ к данным, а это почти всегда означает сначала работу с узлом. Это, безусловно, может оттолкнуть тех разработчиков, которые сотрудничают с платформой для разработки API для внешних клиентов или для собственного использования. Платформы ищут способы сделать это проще, чтобы стимулировать развитие своих пользователей и сделать платформу в целом более надежной. Сдвиг в архитектуре, напрямую связанный с этим, — это Bware Labs, которая делает разработку API ключевой функцией всей своей платформы. Их архитектура настроена таким образом, что владельцы узлов действительно имеют доступ к возможностям разработки API. Но для тех, кто не хочет или не может размещать узел, они также позволяют пользователям выбрать ежемесячную подписку и подписаться на конечную точку, которая обеспечивает прямой доступ к конечной точке и всем данным, необходимым для взаимодействия с разрабатываемыми ими API. Это новая структура, которая помогла Bware Labs расти за счет пользовательских инноваций, а также вознаградить тех новаторов, чьи API-интерфейсы активно используются. Также следует отметить стратегию, используемую CoinGecko, с подробным руководством по разработке API для пользователей.

Подведение итогов

Децентрализация — очевидная тенденция для платформ, и она будет только усиливаться по мере того, как пользователи увидят значительные преимущества, связанные с отсутствием необходимости полагаться на централизованные узкие места, единые точки отказа и потенциально несправедливый отказ в доступе. Но без API децентрализация просто продвигает централизацию вверх по течению. API – это основная функция децентрализованных платформ, которая способствует процветанию, и благодаря тому, что ведущие экосистемы находят способы поощрять их использование, мы намного ближе к реализации всей мощи блокчейна.