net api что это
Что такое API и как он помогает в создании программных систем
Программы, как люди, общаются между собой. Разбираемся, как это происходит с помощью API.
Популярный термин API (англ. Application Programming Interface — программный интерфейс приложения) — это набор способов и правил, по которым различные программы общаются между собой и обмениваются данными.
Все эти коммуникации происходят с помощью функций, классов, методов, структур, а иногда констант одной программы, к которым могут обращаться другие. Это основной принцип работы API.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Почему API называют интерфейсом
Интерфейс — это граница между двумя функциональными системами, на которой происходит их взаимодействие и обмен информацией. Но при этом процессы внутри каждой из систем скрыты друг от друга.
С помощью интерфейса можно использовать возможности разных систем, не задумываясь о том, как они обрабатывают наши запросы и что у них «под капотом». Например, чтобы позвонить, совсем не обязательно знать, как смартфон обрабатывает нажатия на тачскрин. Важно лишь, что у гаджета есть «кнопка», всегда возвращающая одинаковый результат в ответ на определённые действия.
Точно так же с помощью вызовов API можно выполнить определённые функции программы, не зная, как она работает. Поэтому API и называют интерфейсом.
Как API помогают писать надёжные программы
Программную (и не только) систему, внутреннее устройство которой скрыто или не важно при решении текущей задачи, принято называть « чёрным ящиком» — потому что мы не знаем/не принимаем во внимание то, что там происходит. А само сокрытие деталей реализации — уровнем абстракции.
Уровни абстракции сильно ускоряют процесс разработки, потому что программист может использовать готовые функции API в других приложениях. Это обычная практика. Например, большинство операционных систем предоставляют свои API другим программам, чтобы они получили возможность:
Windows, Linux или OS X сами определяют, какие функции нужно вызвать и какие параметры передать, чтобы были выполнены те или иные действия. Всё это описывается в документации к API, с которым работают разработчики других программ.
Если создатели API выпускают обновление, которое исправляет ошибки, устраняет уязвимости или улучшает производительность, все приложения, использующие это API, автоматически станут работать лучше.
Если какой-то API для облачных вычислений станет быстрее извлекать квадратный корень, то и все использующие его программы тоже начнут работать быстрее: от онлайн-калькуляторов до нейросетей.
Почему API так популярны у программистов
Стороннее API обычно безопаснее, потому что над ним работает коммерческая организация или целое сообщество разработчиков.
Какие функций могут входить в API
Никаких специальных правил или ограничений на набор функций для API нет — разработчики включают в него то, что позволит клиентам использовать нужные возможности приложения.
Например, в API для анализа текстов будут функции поиска всех однокоренных слов, подсчёта количества союзов, выявления часто встречающихся словосочетаний и так далее.
Функции API могут решать не только утилитарные задачи конкретных приложений. Это может стать элементом маркетинга, когда доступ к API предлагается в виде отдельной услуги.
Как компании зарабатывают с помощью API
Компании, разрабатывающие сложные программные системы, часто предоставляют клиентам доступ к API своих продуктов. Например, создатели видеоредактора могут брать дополнительную плату за рендеринг видео на своих серверах. По API они принимают от клиентов все файлы и инструкции, а возвращают готовый ролик.
Так, скажем, Яндекс, помимо прочего, предоставляет платный API своих технологий:
Популярные социальные сети тоже предоставляют доступ к своим API. Через них можно, например, создать игру для ВКонтакте или добавить на сайт авторизацию через Facebook.
При этом компании обычно не раскрывают принципы реализации своих API, поэтому для программистов они остаются «чёрными ящиками».
Как происходит вызов функций API
Способ вызова функции API описывается в документации.
Вот пример вызова методов библиотек в языке Python:
Если API предоставляет функции через интернет (WebAPI), нужно отправить на сервер HTTP-запрос с данными в формате JSON. Пример синтеза речи с помощью API Yandex.SpeechKit:
Этого достаточно, чтобы получить следующее аудио:
Также бывают косвенные вызовы API — когда вызов происходит при участии посредника (другой функции или другого API). Например, когда пользователь нажимает кнопку «Обновить», он тоже взаимодействует с API браузера. Но делает это не напрямую, а через графический интерфейс.
Что в итоге
С развитием технологий использование API, вероятно, станет повсеместным. Даже простейшие встраиваемые системы, вроде «умного утюга», которые состоят из одной программы, сейчас всё активнее подключаются к интернету вещей. Для этого тоже используют API.
Программисту нужно не только уметь создавать свои интерфейсы для взаимодействия программ, но и знать, как использовать чужие. Научиться работать с API вы сможете на наших курсах по программированию — выбирайте любой и становитесь востребованным специалистом.
Что такое API
Содержание
— А зачем это мне? Я вообще-то web тестирую! Вот если пойду в автоматизацию, тогда да… Ну, еще это в enterprise тестируют, я слышал…
А вот и нет! Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой. И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.
Любая оплата идет через API платежной системы. Купил билет в кино? Маечку в онлайн-магазине? Книжку? Как только жмешь «оплатить», сайт соединяет тебя с платежной системой.
Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api. И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:
Что такое API
API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».
Если переводить на русский, это было бы слово «договор». Договор между двумя сторонами, как договор на покупку машины:
API — набор функций
Когда вы покупаете машину, вы составляете договор, в котором прописываете все важные для вас пункты. Точно также и между программами должны составляться договоры. Они указывают, как к той или иной программе можно обращаться.
Соответственно, API отвечает на вопрос “Как ко мне, к моей системе можно обратиться?”, и включает в себя:
Тут вы можете мне сказать:
— Хмм, погоди. Операция, данные на входе, данные на выходе — как-то всё это очень сильно похоже на описание функции!
Если вы когда-то сталкивались с разработкой или просто изучали язык программирования, вы наверняка знаете, что такое функция. Фактически у нас есть данные на входе, есть данные на выходе, и некая магия, которая преобразует одно в другое.
И да! Вы будете правы в том, что определения похожи. Почему? Да потому что API — это набор функций. Это может быть одна функция, а может быть много.
Как составляется набор функций
Да без разницы как. Как разработчик захочет, так и сгруппирует. Например, можно группировать API по функционалу. То есть:
Можно не группировать вообще, а делать одно общее API.
Можно сделать одно общее API, а остальные «под заказ». Если у вас коробочный продукт, то в него обычно входит набор стандартных функций. А любые хотелки заказчиков выносятся отдельно.
Получается, что в нашей системе есть несколько разных API, на каждое из которых у нас написан контракт. В каждом контракте четко прописано, какие операции можно выполнять, какие функции там будут
И конечно, функции можно переиспользовать. То есть одну и ту же функцию можно включать в разные наборы, в разные апи. Никто этого не запрещает.
Получается, что разработчик придумывает, какое у него будет API. Либо делает общее, либо распределяет по функционалу или каким-то своим критериям, и в каждое апи добавляет тот набор функций, который ему необходим.
При чем тут слово «интерфейс»
— Минуточку, Оля! Ты же сама выше писала, что API — это Application programming interface. Почему ты тогда говоришь о контракте, хотя там слово интерфейс?
Да потому, что в программировании контракт — это и есть интерфейс. В классическом описании ООП (объектно-ориентированного программирования) есть 3 кита:
Не всегда программа предоставляет именно графический интерфейс. Это может быть SOAP, REST интерфейс, или другое API. Чтобы использовать этот интерфейс, вы должны понимать:
Как вызывается API
Вызвать апи можно как напрямую, так и косвенно.
Вызов API напрямую
1. Система вызывает функции внутри себя
Разные части программы как-то общаются между собой. Они делают это на программном уровне, то есть на уровне API!
Это самый «простой» в использовании способ, потому что автор API, которое вызывается — разработчик. И он же его потребитель! А значит, проблемы с неактуальной документацией нет =)
Шучу, проблемы с документацией есть всегда. Просто в этом случае в качестве документации будут комментарии в коде. А они, увы, тоже бывают неактуальны. Или разработчики разные, или один, но уже забыл, как делал исходное api и как оно должно работать…
2. Система вызывает метод другой системы
А вот это типичный кейс, которые тестируют тестировщики в интеграторах. Или тестировщики, которые проверяют интеграцию своей системы с чужой.
Одна система дергает через api какой-то метод другой системы. Она может попытаться получить данные из другой системы. Или наоборот, отправить данные в эту систему.
Допустим, я решила подключить подсказки из Дадаты к своему интернет-магазинчику, чтобы пользователь легко ввел адрес доставки.
Я подключаю подсказки по API. И теперь, когда пользователь начинает вводить адрес на моем сайте, он видит подсказки из Дадаты. Как это получается:
И, конечно, не забываем про кейс, когда мы разрабатываем именно API-метод. Который только через SOAP и можно вызвать, в интерфейсе его нигде нет. Что Заказчик заказал, то мы и сделали ¯\_(ツ)_/¯
Пример можно посмотреть в Users. Метод MagicSearch создан на основе реальных событий. Хотя надо признать, в оригинале логика еще замудренее была, я то под свой сайт подстраивала.
Но тут фишка в том, что в самой системе в пользовательском интерфейсе есть только обычный поиск, просто строка ввода. Ну, может, парочка фильтров. А вот для интеграции нужна была целая куча доп возможностей, что и было сделано через SOAP-метод.
Функционал супер-поиска доступен только по API, пользователь в интерфейсе его никак не пощупает.
В этом случае у вас обычно есть ТЗ, согласно которому работает API-метод. Ваша задача — проверить его. Типичная задача тестировщика, просто добавьте к стандартным тестам на тест-дизайн особенности тестирования API, и дело в шляпе!
(что именно надо тестировать в API — я расскажу отдельной статьей чуть позднее)
3. Человек вызывает метод
Для примера снова идем в Users. Если мы хотим создать пользователя, надо заполнить уйму полей!
Конечно, это можно сделать в помощью специальных плагинов типа Form Filler. Но что, если вам нужны адекватные тестовые данные под вашу систему? И на русском языке?
Заполнение полей вручную — грустно и уныло! А уж если это надо повторять каждую неделю или день на чистой тестовой базе — вообще кошмар. Это сразу первый приоритет на автоматизацию рутинных действий.
И в данном случае роль автоматизатора выполняет… Postman. Пользователя можно создать через REST-запрос CreateUser. Один раз прописали нормальные “как настоящие” данные, каждый раз пользуемся. Профит!
Вместо ручного заполнения формы (1 минута бездумного заполнения полей значениями «лпрулпк») получаем 1 секунду нажатия на кнопку «Send». При этом значения будут намного адекватнее.
А еще в постмане можно сделать отдельную папку подготовки тестовой базы, напихать туда десяток запросов. И вот уже на любой базе за пару секунд вы получаете столько данных, сколько вручную вбивали бы часами!
Если вы нашли баг и не понимаете, на кого его вешать — разработчика front-end или back-end, уберите все лишнее. Вызовите метод без графического интерфейса. А еще вы можете тестировать логику программы, пока интерфейс не готов или сломан.
4. Автотесты дергают методы
Есть типичная пирамида автоматизации:
Слово API как бы намекает на то, что будет использовано в тестах ツ
GUI-тесты — честный тест, робот делает все, что делал бы пользователь. Открывает браузер, тыкает на кнопочки… Но если что-то упадет, будете долго разбираться, где именно.
API-тесты — все то же самое, только без браузера. Мы просто подаем данные на вход и проверяем данные на выходе. Например, можно внести итоговый ответ в эксельку, и пусть робот выверяет ее, правильно ли заполняются данные? Локализовать проблему становится проще.
Unit-тесты — это когда мы проверяем каждую функцию отдельно. Отдельно смотрим расчет для ячейки 1, отдельно — для ячейки 2, и так далее. Такие тесты шустрее всего гоняются и баги по ним легко локализовать.
Косвенный вызов API
Когда пользователь работает с GUI, на самом деле он тоже работает с API. Просто не знает об этом, ему это просто не нужно.
То есть когда пользователь открывает систему и пытается загрузить отчет, ему не важно, как работает система, какой там magic внутри. У него есть кнопочка «загрузить отчет», на которую он и нажимает. Пользователь работает через GUI (графический пользовательский интерфейс).
Но на самом деле под этим графическим пользовательским интерфейсом находится API. И когда пользователь нажимает на кнопочку, кнопочка вызывает функцию построения отчета.
А функция построения отчета уже может вызывать 10 разных других функций, если ей это необходимо.
И вот уже пользователь видит перед собой готовый отчет. Он вызвал сложное API, даже не подозревая об этом!
Что значит «Тестирование API»
В первую очередь, мы подразумеваем тестирование ЧЕРЕЗ API. «Тестирование API» — общеупотребимый термин, так действительно говорят, но технически термин некорректен. Мы не тестируем API, мы не тестируем GUI (графический интерфейс). Мы тестируем какую-то функциональность через графический или программный интерфейс.
Но это устоявшееся выражение. Можно использовать его и говорить “тестирование API”. И когда мы про это говорим, мы имеем в виду:
Когда мы говорим про тестирование API, чаще всего мы подразумеваем тестирование Remote API. Когда у нас есть две системы, находящихся на разных компьютерах, которые как-то между собой общаются.
И если вы видите в вакансии «тестирование API», скорее всего это подразумевает умение вызвать SOAP или REST сервис и протестировать его. Хотя всегда стоит уточнить!
Резюме
API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».
.NET API в веб-разработке: прошлое и будущее
Многие думают, что создание API — специфичный процесс, и понимать его нужно лишь тем, кто профессионально занимается разработкой API-проектов. Но в реальности все мы так или иначе пишем API: для новых классов, сервисов, для коллег или заказчиков.
Под катом мы постарались подобрать для вас несколько практических советов о том, как создавать дизайн веб API, планировать изменения, управлять версионированием и взаимодействовать с пользователями API. Мы постарались выяснить, какие сложности могут возникнуть и какие типичные ошибки обычно совершаются. А также прочитать о различных интересных фактах из истории и об ожидаемых изменениях в будущем.
Наш сегодняшний собеседник Дилан Битти (Dylan Beattie) имеет высокую репутацию на StackOverflow, а значит умеет хорошо, интересно и, что немаловажно, правильно отвечать на вопросы. Большой опыт позволяет ему на собственных примерах рассказать что-то из прошлого, а профессия архитектора держит в тонусе и приносит новые знания о трендах и передовых технологиях.
– Какие API вы разрабатываете? В какой именно момент дизайн API вдруг переходит в разработку ПО?
Дилан Битти: Это очень интересный вопрос, потому как я думаю, что одним из самых больших заблуждений в сфере разработки софта является то, что дизайн API — это что-то, что происходит отдельно от всего остального. Конечно же, есть определенные типы API-проектов, такие как HTTP APIs, которые будут открыты публично — и здесь есть смысл рассматривать дизайн как отдельную часть работы. Но правда в том, что большинство разработчиков, собственно, создает API постоянно, — они просто не осознают сами, что они это делают. Каждый раз, когда вы пишете public method в одном из ваших классов или выбираете имя для таблицы базы данных, вы создаете интерфейс — в обычном ежедневном английском значении этого слова — это то, что в конце концов будет использоваться другими разработчиками в определенный момент времени в будущем. Другие люди вашей команды будут использовать ваши классы и методы. Другие команды будут использовать вашу схему данных или формат сообщений.
Что интересно, так это то, что если разработчики понимают, что код, над которым они работают, скорее всего станет частью API, то их слишком сильно клонит в одну и ту же сторону. Они начинают реализовывать edge case-ы и всякие другие штуки, которые особо им и не нужны, просто потому, что они могут понадобится кому-нибудь после. Я думаю, что тут нужно тонко чувствовать грань, и мне кажется, что ключ к пониманию этой грани в том, что нужно быть предельно конкретным в создании набора функций, который вам необходим именно сейчас. Но важно делать этот набор насколько только возможно повторно применяемым и самоописываемым. У Pieter Hintjens есть хорошее эссе под названием Ten Rules for Good API Design, которое дает более подробное представление об идеях подобного типа.
Самый большой API-проект, над которым я работаю на данный момент, это тот, который я делаю в английской компании Spotlight. Это гипермедийное API, раскрывающее различную информацию о профессиональных актерах. Предложения работы в актерских проектах, в кино и на телевидении и различные другие данные, используемые в индустрии кастинга. Мы строим этот API на архитектурном стиле, известном как REST, — и если вы не совсем в курсе, что такое REST, то вы просто обязаны прийти на мое выступление на конференции DotNext в Санкт-Петербурге и узнать об этом.
Существуют различные паттерны для создания HTTP API — есть REST, есть GraphQL, есть такие штуки, как SOAP и RPC. Но для меня самая большая привлекательность REST состоит в том, что ограничения RESTful-стиля ведут к натуральному ослаблению связей в концептах и операциях, которые ваш API должен поддерживать, что позволяет с большей легкостью вносить изменения и развивать дизайн в течение продолжительного времени.
– Одно из самых известных программ, «убитых» обратной совместимостью, это IE. Этот браузер имел слишком много приложений, для которых необходимо было сохранять совместимость с предыдущими версиями. Проблема была решена простым добавлением нового приложения под названием Edge, которое обновляемо и поддерживает все новые стандарты. Как не попасть в ловушку обратной совместимости? Может быть, стоит использовать модульность, которая в свою очередь не использует слои? Или, может быть, как-то заменить API с помощью RESTful API, Service Oriented Architecture или чего-либо еще?
Дилан Битти: Я начал создавать веб-приложения давно. Свою первую страницу написал за пару лет до появления Internet Explorer. Тогда, когда единственными браузерами были NCSA Mosaic и Erwise. Это завораживает — смотреть назад в историю веба и осознавать то, что веб, который существует сейчас, был смоделирован и подвержен влиянию таких вещей как Internet Explorer. И вы совершенно правы; одна из причин, почему Microsoft представила полностью новый браузер Edge в последних версиях Windows, это то, что обязательства Internet Explorer поддерживать обратную совместимость сделали работу по реализации новых веб-стандартов на существующей базе кода IE очень сложной.
Часть причин, по которым эта обратная совместимость в IE существует, заключается в том, что около 2000-ого года произошел небольшой сдвиг в способе разработки корпоративных IT-систем.
Существует бесчисленное количество компаний, у которых есть собственные приложения для различных видов бизнес-операций: контроля акционерного капитала, учета товара, HR, менеджмента проектов и других. В 1980-х и ранних 1990-х большинство из них использовали систему с центральным мейнфреймом, и сотрудники применяли что-то вроде терминального эмулятора, чтобы подключится к центральному серверу. Но после первой волны доткомов в конце 1990-х компании осознали, что у большинства их компьютеров сейчас есть веб-браузер и подключение к сети, и они могут заменить старые терминальные приложения мэйнфрейма новыми веб-приложениями.
Windows на тот момент занимала колоссальную долю рынка, и Internet Explorer был браузером по-умолчанию на большинстве Windows PC, так что многие организации построили intranet-приложения, которые работали только с определенной версией Internet Explorer. Иногда они делали это для того, чтобы получить преимущества специфических фич, таких как ActiveX-поддержка; но чаще, я думаю, они делали это, просто чтобы сэкономить деньги за счет того, что им не нужно было проводить кросс-браузерное тестирование. Так произошло и с некоторыми довольно большими коммерческими приложениями; даже в 2011 году Microsoft Dynamics CRM все еще не поддерживал никакие другие браузеры кроме Internet Explorer.
Таким образом и у нас появилось большое количество компаний, которые инвестировали время и деньги в создание приложений, работающих с Internet Explorer. Эти приложения не были созданы с использованием веб-стандартов или прогрессивного улучшения или же с какой-либо попыткой создать совместимость с последующими версиями — они явным образом разрабатывались для одной конкретной версии браузера, работающего на операционной системе. И каждый раз, когда Microsoft выпускала новую версию Internet Explorer, эти приложения «падали» — а компании не хотели инвестировать в обновление их устаревших интранет-приложений и винили во всем браузер. Но история не закончена: сейчас в 2017 году Microsoft все еще поставляет IE11, у которого есть режим совместимости, где он переключается к движку IE9, но при этом отправляет user agent string, что он IE7. Сейчас все, кого я знаю, используют Google Chrome или Safari для серфинга в сети, но при этом на рабочем столе у многих все еще «живет» ярлык IE, через который можно войти в одну из legacy-систем.
– Предположим, что некто собирается представить новый API. Он собирает некоторые требования, предлагает версию и получает feedback. Процесс выглядит нехитрым и простым. Но есть ли какие-то подводные камни на пути?
Дилан Битти: Всегда! Требования будут изменены — это факт. Одна из самых больших ошибок, которую вы можете совершить, — попробовать предвидеть эти изменения и сделать свой дизайн «future-proof». Теоретически это может окупиться, но чаще всего вы оказываетесь с еще более сложным дизайном на руках, поскольку старались заложить в него какие-либо будущие изменения. Часто подводные камни — это то, что находится вне вашего контроля. Например, изменится закон, и вам потребуется иначе предоставить данные. Или произойдут изменения в других системах вашей организации. Или один из ваших облачных хостинг-провайдеров заявит, что они перевели какую-то необходимую вам функцию в разряд устаревших.
Лучше всего выбрать из возможных вариантов интерфейса что-то простое и пригодное к использованию, сделать и сдать это. Чтобы максимально быстро перейти к этапу, когда ваш API работает стабильно, нет никакого внешнего технического долга, и команда может двигаться к следующей задаче. Так что если вы после этого вдруг столкнетесь с какой-либо непредвиденной проблемой, то у вас при этом будет стабильная кодовая база, готовая к использованию в вашем решении, и команда, у которой будет время и желание работать для того, чтобы все решить. А если по какому-нибудь стечению обстоятельств вам не попадется никакой подводный камень, вы сможете просто перейти на следующий пункт в своем бэклоге.
– Вот мы выпустили версию v1.0 нашего API и на подходе v1.1. Наверное, многие из нас создадут и http://example.com/v1/test, и http://example.com/v1.1/test или что-то в этом роде. Какие практики, по вашему мнению, могут помочь разработчику сделать дизайн v1.1 API лучшим по отношению к v1.0?
Дилан Битти: Было бы хорошо прочитать о концептах семантического версионирования (SemVer) и потратить время на то, чтобы действительно понять различия между major, minor и patch версиями. SemVer говорит, что у вас не должно быть никаких критических изменений между версиями 0.x и 0.1, так что самая важная часть — это понять что будет являться критическим изменением для вашего конкретного API.
Если вы работаете с HTTP API, которые возвращают JSON, например, то типичным не критическим изменением будет добавление нового поля данных в один из ваших ресурсов. Ожидается, что клиенты, которые используют версию 1.1, увидят дополнительное поле и смогут получить все преимущества от этого, в то время как клиенты, которые все еще используют версию 1.0, смогут не учитывать нераспознанное свойство. Это еще один довольно близкий вопрос о том, как вы должны управлять версионированием ваших API. Одно из самых популярных решений — представлять URL через роутинг — api.example.com/v1/ вместо api.example.com/v1.1
Но если вы соблюдаете ограничения RESTful систем, то вам необходимо понять, будет ли изменение в версии представлять изменение лежащего в основе ресурса или же представления. Помните, что URI это Uniform Resource Identifier, и мы действительно не должны изменять URI, который мы используем, чтобы направить на тот же ресурс.
Например, у нас есть ресурс api.example.com/images/monalisa. Мы можем запросить этот ресурс как JPEG (Accept: image/jpeg) или как PNG (Accept: image/png), или спросить сервер, есть ли у него plain-text представление этого ресурса (Accept: application/json) – но это все только различные представления одного и того же лежащего в основе ресурса, и они все должны иметь одинаковый URI.
Или, скажем, вы полностью заменили CRM-систему, используемую в вашей организации, и в этом случае «версия 1» клиента представляет запись, которая используется в старой CRM-системе, и «версия 2» представляет того же клиента, но после мигрирования на полностью новую платформу. В таком случае, пожалуй, имеет смысл рассматривать их как различные ресурсы и дать им различные URI.
Версионирование — штука сложная. Проще всего никогда ничего не изменять.
– Гибкость API vs точность API. Можно создать дизайн API-метода с возможностью получить множество различных типов значений. Но можно и создать метод с некоторыми правилами в параметрах. Оба пути верные. Где граница между этими двумя возможностями? Когда мы должны делать строгий API, а когда создавать гибкий API дизайн?
Дилан Битти: При реализации API, в котором сигнатуры метода гибкие, все, что вы делаете, это отправляете сложность куда-то еще в вашем стеке. Скажем, мы создаем API для нахождения лыжных путевок, и у нас есть выбор между DoSearch(SearchCriteria criteria) и DoSearch(string resortName, string countryCode, int minAltitude, int maxDistanceToSkiList).
Первый из этих методов довольно легко расширяем. Мы ведь можем расширить определение объекта SearchCriteria без смены сигнатуры метода. Но в таком случае мы не просто изменяем конкретный метод — мы еще изменяем и поведение системы.
В противоположность мы можем добавить новые аргументы в сигнатуру нашего второго DoSearch метода. Если мы работаем с таким языком как C#, то мы можем предоставить аргументам значения по умолчанию. И мы ничего не сломаем в проекте, добавляя новые аргументы в метод, если при этом зададим разумные значения по умолчанию этим самым аргументам.
Думаю, в следующее десятилетие мы с вами увидим полностью иную категорию API, приводимую в движение системами машинного обучения, где множество повсеместно принятых правил API-дизайна не будут применяться. Меня совершенно не удивит, если мы вдруг получим API поиска лыжных путевок, где вам необходимо просто указать, что вам нужно, на нормальном языке. И тут даже не будет сигнатуры метода — вы просто вызываете что-то вроде DoSearch («ski chalet, in France or Italy, 1400m or higher, that sleeps 12 people in 8 bedrooms, available from 18-25 January 2018») — и лежащая в основе система сделает все за вас. Эти способы разработки с помощью машинного обучения — захватывающая вещь. Но их создатели хотят сделать еще несколько интересных для разработчиков и дизайнеров изменений, чтобы привлечь к себе дополнительное внимание.