Еще в 1996 году, когда я присоединился к компании EDI в качестве программиста, первым делом коллега положил на свой рабочий стол справочную информацию по API для Windows —
программирование Windows Чарльза Петцольда . В то время мы программировали для Windows 3.1 (и для чего-то под названием «DOS Windows» — не спрашивайте …). Я могу вспомнить волнение в нашей маленькой группе программистов, когда вышел
5-й выпуск «Petzold» , как мы его называли. Этот тяжелый том был «Полное руководство по Win32 API».
В то время API понимали как C ++ или Visual Basic. MAPI (Почтовый API для Windows) является хорошим примером. В то время я писал клиенты EDI, используя продукты ISOCOR, а один, в частности, Personal ISOTrade, реализовал MAPI API. Таким образом, с этим продуктом все, что нам нужно было сделать, это реализовать этот API для отправки сообщений EDI (EDIFACT и HL7) через X.400. В то время я также занимался программированием на Java и использовал наборы инструментов Java (например, J / Crypto, который представлял собой полноценную реализацию JCA / JCE), но это были наборы инструментов или реализации интерфейсов, не совсем такие же, как «API».
Перенесемся на десять лет вперед. Принципы сервис-ориентированной архитектуры получили распространение, даже если название «SOA» оставалось спорным. Понятие
Услугзаменены API. Вы все еще можете использовать настоящие программные API, но при этом понималось, что на самом деле вы используете
сервис, который не должен быть привязан к конкретному языку. Такое мышление освобождает и открывает все возможности. Постепенно API-интерфейсы могут быть представлены более широко используемым способом. И мы говорили об «сервисах», а не «API».
Дэрил Пламмер хорошо сказал,
что
«кто-то сказал мне», если вы старше 30 лет, вы называете это «API», а если вам меньше 30, вы называете это «услугой» »).
Но что случилось потом? В 2011 году, когда мы говорим об «API», мы имеем в виду веб-API, подобные тем, которые есть в этом
огромном списке веб-API., Сейчас дети снова говорят об API, но не так, как 15 лет назад. Взять
хотя бы API USA Today Sports Salaries . Вы заинтересованы в том, чтобы узнать, сколько зарабатывает конкретный американский спортивный игрок? Затем этот API получит информацию, используя HTTP-запрос и получив ответ в формате JSON или RSS (XML).
Одно большое различие между старыми API C ++ / VB и современными веб-API состоит в том, что управление API и безопасность не рассматривались 15 лет назад. Были исключения, такие как крипто-API, которые включали элементы управления против злоумышленников, которые заменяли свои собственные реализации API-интерфейса атакой. Но в основном API вызывались в контексте пользовательского приложения, и безопасность была на этом уровне (т. Е. «Пользователь должен был войти в систему, чтобы использовать приложение»). И использование API обычно не отслеживалось.
Но сейчас управление API и безопасность важны. Чтобы понять почему, проверьте
страницу API USA Today Sports Salary снова. Доступ к этому API управляется с помощью ключа API:
Каждый вызов API США TODAY Salaries должен проходить проверку подлинности с помощью уникального ключа API программиста, как в этом примере запроса.
http://api.usatoday.com/open/salaries?api_key=XXXXXX
USA Today использует этот ключ разработчика, чтобы ограничить доступ к своей ценной базе данных спортивных зарплат до 1000 запросов в день. Тем не менее, ключ API в приведенном выше примере отправляется через (yikes) простой HTTP, так что самозванец может выхватить чужой ключ API из сообщения и затем использовать его, чтобы высосать спортивные зарплаты из своей учетной записи. Все это указывает на необходимость управления API и безопасности. К счастью, есть варианты для безопасности API , поэтому раскрытие Web API не должно означать вывешивание ваших данных для доступа к миру через простой HTTP. С сервисным шлюзом довольно просто создать политику, которая применяет SSL, устанавливает ограничения на использование и обеспечивает мониторинг API.
SalesForce.com — один из моих любимых веб-API для использования в демоверсиях. SalesForce имеет массу информации об их API на своем сайте разработчиков . Vordel можно использовать для подключения к SalesForce, включая отправку ключа API и кэширование идентификатора сеанса, который возвращается SalesForce.
Одна из приятных вещей в этом заключается в том, что весь трафик от приложения к SalesForce API теперь проходит проверку подлинности и мониторинг и отображается в браузере, как показано ниже:
Итак, API и сервисы прошли полный круг. 15 лет назад все было связано с API. Тогда это было все об услугах. Теперь мы снова поговорим об API, но имеем в виду нечто иное, чем мы тогда. Безопасность и управление этими новыми API-интерфейсами достигли своей цели, но хорошая новость заключается в том, что есть решения для этого.