Эта статья пытается ответить на вопрос, который можно легко задать в наши дни: почему все одержимы API и как их создавать?
Клиент и сервер
Десять лет назад работа веб-сервера состояла в том, чтобы создавать HTML-страницы и обслуживать тупой уровень представления для клиента; Роль JavaScript заключалась в переопределении тега <blink> кросс-браузерным способом.
Теперь, когда у нас есть возможность запустить надежную машину Тьюринга в браузере и выполнять вызовы Ajax, она стала реальной возможностью перекладывать на нее все больше обязанностей и код JavaScript.
Крайний конец этого спектра состоит из одностраничных приложений, которые никогда не перезагружаются, а только обновляют части окна через XMLHttpRequest. Разговор с сервером — это не серия полных HTML-страниц для загрузки, а набор небольших запросов:
POST /users GET /users/1 #following the redirect PUT /users/1/enabled
все из которых возвращают не представление HTML, а представление JSON или XML.
На прошлой неделе я слушал выступление Габриэле Ланы в Милане, где он описал, как принятие протокола на основе HTTP является естественным для разделения бизнес-логики (предоставляемой сервером) и представления (выполняемой клиентом на JavaScript). Даже если вам нужно обслуживать только HTML-страницы, API принудительно разделяет два уровня и позволяет бизнес-серверу или серверу переднего плана независимо изменять свою реализацию, язык и конфигурацию компьютера.
Новые возможности
Помимо переписывания вашего внешнего интерфейса во Flex или вашей бизнес-логики в Scala из-за четкой границы, есть несколько возможностей, которые открывает HTTP (я не смею называть это REST):
- могут быть созданы новые внешние интерфейсы: первыми в голову приходят мобильные версии веб-приложений и мобильные нативные приложения. Бизнес-логика остается общей, в то время как внешние интерфейсы создаются по-новому для каждого вида пользовательского интерфейса.
- интеграция других приложений осуществляется не путем совместного использования базы данных, а путем доступа к более строгому API, который разделяет несколько действий, доступных интегратору, вместо предоставления каждой таблицы, позволяя приложению на основе API развиваться как можно более независимо и избегать неожиданностей, когда модель данных меняется.
- Возможное деловое преимущество заключается в предоставлении доступа к API-интерфейсам другим вашим приложениям.
- Если ваше приложение делает что-то интересное, вы также можете предоставить доступ другим людям (даже за плату). Это особенно верно, если приложение работает над чем-то более сложным для интеграции, например, с устройствами, обычно отключенными от Интернета, такими как датчики.
- Идея открытых данных состоит в том, чтобы предоставить API только для чтения для доступа к правительственным данным, который сам бы размещался на жестком диске, если был открыт только через оригинальный общедоступный веб-сайт.
Испытания
Браузеры не способны выполнять запросы PUT или DELETE, оставляя только GET и POST доступными для доступа к API. Эта проблема приводит к использованию фиктивного параметра, добавляемого к URL-адресу, чтобы сообщить серверу, что текущий перегруженный запрос POST должен рассматриваться как другой метод:
POST /users/1/enabled?_method=put
POST используется поверх GET для поддержки семантики небезопасного метода, который изменяет состояние приложения. Неясно , будет ли HTML 5 требовать поддержки запросов PUT и DELETE в формах.
Другой проблемой является задержка, время прохождения сигнала в оба конца, необходимое для удовлетворения минимального HTTP-запроса; были такие эксперименты, как SPDY, чтобы попытаться снизить задержку, но инициирование множества различных Ajax-запросов для создания фрагментов страницы на клиенте может создать нагрузку на канал; браузеры обычно выполняют только 6 параллельных запросов на домен одновременно. К счастью, вы можете, по крайней мере, кэшировать каждый фрагмент страницы независимо друг от друга без необходимости использования ускорителя HTTP, такого как Varnish.
история
Последняя потенциальная проблема связана с управлением историей или с тем, как не сломать кнопку «назад»: по умолчанию завершенные запросы Ajax не изменяют URL-адрес, отображаемый в строке адреса, что означает, что с ним невозможно достичь предыдущего состояния страницы. ,
В прошлом хэш-банги, такие как #! StateName, добавлялись в текущее местоположение, чтобы одновременно избежать перенаправления и предоставить новый заполнитель URL. Теперь HTML 5 History предоставляет (во все большем и большем количестве браузеров) API для изменения URL-адреса в реальном, позволяя вам изменять / users в / users / 1 без перезагрузки страницы.
Это даже разлагаемое улучшение, поскольку вы можете предоставлять реальные ссылки на новые местоположения (которые будут работать в старых браузерах) и перехватывать их событие click, чтобы загружать фрагменты с помощью Ajax, обновляя историю с помощью JavaScript.
Выводы
Можно использовать JSON или XML API в качестве конечной точки HTTP-сервера, учитывая текущее состояние функций браузера; Более того, универсальный вариант HTTP сделает одну и ту же бизнес-логику доступной повсюду. Даже внутренние части вашего приложения (Bounded Context) могут извлечь выгоду из извлечения и интеграции с API, который позволит им развиваться независимо в технологии, вариантах развертывания (сколько серверов?) И даже в языке.