Tag Archives: HATEOAS

HATEOAS: реализация функций в RESTful API

Я не знаю кто и когда придумал аббревиатуру HATEOAS, означающую Hypermedia As The Engine Of Application State. Выглядит она страшно, а звучит непонятно. В общем разбираться с тем что это такое и зачем оно нужно совершенно не хочется. Из-за этого потенциал, заложенный в архитектурный стиль REST и позволяющий создавать довольно интересные программные интерфейсы остается не раскрытым. Но обо всем по порядку. Читать далее


Почему не все сервисы одинаково полезны

inversionВ программировании известен такой архитектурный паттерн как Inversion Of Control. Суть его в следующем. Традиционно, повторно используемый код оформлялся в виде функций, которые впоследствии вызывались из основной программы. Функции оформлялись в виде статических библиотек, динамических библиотек или вообще в виде сервисов. Приходил программист. Брал функциональные требования, реализовывал бизнес-логику в виде отдельной программы, которая при необходимости вызывала эти самые функции. Inversion Of Control переставляет все с ног на голову. Мы пишем готовую программу, внутри которой реализуем повторно используемый функционал. При этом мы предусматриваемые некоторые точки расширения, в которых вызываются функции, реализующие бизнес-логику. В качестве примера можно привести функцию обработки сообщений главного окна приложения Windows именуемую MainWndProc(). В объектно-ориентированном программировании приложение часто наследуется от некоторого базового класса. Читать далее


Масштабируемость RESTful web-сервисов

Representational State Transfer это не только эффективный стиль для архитектуры данных и приложений. Безусловно, очень удобно, когда у каждого информационного ресурса есть неизменный URL.  Такую гиперссылку можно сохранить или переслать коллеге, избавив информационные системы от повторного поиска. Но придумывался REST, как впрочем и HTTP, не только для этого. Основная задача этой архитектуры заключалась в построении масштабируемых многоуровневых приложений. Не смотря, на очевидность и простоту этой архитектуры, очень многие разработчики корпоративных информационных систем её не понимают (или делают вид, что не понимают). Поэтому, очередной взгляд на эту архитектуру. На этот раз с точки зрения инфраструктуры. Читать далее


Мобилизация корпоративных информационных систем и дилемма инноватора

Если бы лет пять назад вы спросили программиста, будет ли в будущем его приложение работать на андроиде то, в лучшем случае, он счел бы вас эксцентричным фанатом «Звездных войн». Сегодня вопрос предоставления сотрудникам доступа к корпоративной информационной системе с мобильных устройств звучит вполне обыденно. Вопрос не в том, предоставлять ли такой доступ, а скорее — как это сделать. Очевидный ответ на него: разработать для приложений мобильные клиенты – мне представляется нечестным и трудно реализуемым. На протяжении последних пятнадцати лет мы регулярно переписываем свои корпоративные системы. Сначала мы переписывали их в архитектуру клиент-сервер, потом переписывали на Java, затем готовили к проблеме 2000. С появлением серверов приложений мы снова их переписывали. Читать далее


Одна из ошибок при переходе от инхауса к аутсорсингу

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