Почему нужно искать новое, прямое решение по передаче данных

Надежный интерфейс прикладного программирования (API) стал необходимым для современных успешных независимых поставщиков программного обеспечения SaaS (ISV). Если вы поставщик SaaS, то вы должны ожидать, что большинству ваших клиентов потребуется совместимость с другими приложениями SaaS, веб-службами и устаревшими системами.

Как показали пионеры Интернета Google, Amazon и Facebook, стратегия открытых приложений способствует более глубокому использованию клиентов и обеспечивает новые потоки доходов. Интеграция имеет решающее значение для поставщиков SaaS, и разработка надежной стратегии API является первым шагом к достижению этой цели.

API как структура

К сожалению, многие ISV по-прежнему рассматривают свой API как запоздалую мысль или просто “флажок” в списке своих проектов, а не как основную функцию своего решения. В результате API-интерфейсы плохо спроектированы или должным образом построены и в конечном итоге обходятся как поставщику, так и его клиентам в десятки тысяч долларов постоянного обслуживания из-за затрат на инфраструктуру и утечки инженерных ресурсов.

После просмотра сотен реальных API SaaS, многие из которых соответствуют стандарту, а другие явно не соответствуют, становится ясно, что существует ряд распространенных ошибок, допущенных при разработке API. К счастью, каждый из них можно легко исправить, следуя лучшим практикам.

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

api Почему нужно искать новое, прямое решение по передаче данных
Структура API

Каждая API состоит из собственно каркаса (логической структуры), экземпляров (API instance) и функционального кода, содержащего определенный набор инструкций (API inplementation). Вместе все это и образует набор API.

Клиент-сервер и основная функция API

SSH, FTP, и прочие приложения типа “Клиент-сервер” работают с помощью API. Новое же решение должно работать напрямую, как данные, переданные в JSON или SQL. В связи с этим клиента не потребуется. Мы не берем в счет здесь “железные” компоненты, такие как шины, и не будем о них говорить вообще. Нас интересует именно программная составляющая.

Мои рассуждения могут показаться вам бредовыми, но вспомните, сколько раз уже хакеры уводили данные. Из-за неправильно разработанных протоколов защиты или намеренно оставленных в приложении брешей мы даже не ежегодно – ежедневно теряем большое количество данных. А данные сейчас – основной элемент, с которым мы работаем. Та же утечка мозгов – тоже потеря данных. Но я отвлекся.

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

Новое решение: значение

Новое решение должно:

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

Заключение

Итак, я кратко (и малость сбивчиво) описал вам свои мысли на тему нового решения по передаче данных. Думайте, дорабатывайте и представляйте. Знаете, в СССР была очень хорошая практика – людям давали простор для фантазии. Поэтому появлялись новые прототипы и решения. Тот же самый “Зил” не стал бы таким популярным без таланта его конструкторов, жаль что такое предприятие рухнуло. Все в ваших руках. И не позволяйте никому над вами смеяться, так как именно ваше решение может быть ключевым. Как и эта моя статья.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.