А ваша служба є RESTful? Все що необхідно/обов'язково знати про веб служби та REST

Введення
От не люблю я винаходити велосипед і статтю я б не написав, але довелося. Про REST сказано вже досить багато. Багато постачальники веб служб готові клястися, що їх служби є RESTful. Під час співбесіди ви точно почуєте хоча б декілька питань про REST, незалежно від того це співбесіди для бекенд, мобайл або фронтенд розробника. Я от пам'ятаю якось під час одного співбесіди мене поставили таке запитання: «Ось ви написали в своєму резюме, що знайте REST․ Скажіть будь ласка, якою HTTP код ви отримаєте, якщо при запиті до RESTful сервісу ресурс не знайдено?». Відповідь 404 був прийнятий одноголосно. Якщо чесно, я так і не зрозумів, як це питання допоміг зрозуміти знаю я REST чи ні, але одне можу впевнено сказати: REST розуміють далеко не всі. Ось деякі питання, які мучили мене довгий час:

  1. Навіщо REST став таким трендовим? Це архітектура була ж запропонована ще в 2000 році?
  2. Що я отримаю якщо моя служба буде RESTful?
  3. Як визначити чи є служба RESTful чи ні?
  4. Як правильно повинні створюватися URL REST служб?
  5. http Які методи і коди повинні бути використані в RESTful службі?
Якщо ви не можете дати вичерпної відповіді хоча б на одне з цих питань, то продовжуйте читання. Якщо ви можете однозначно відповісти на всі ці питання, можете привести формат правильного URL, вважайте, що GET, POST, PUT, DELETE обов'язково повинні відповідати CRUD операцій з ресурсами, то вам обов'язково треба продовжувати читання.

Читати далі →

Як я навчився не хвилюватися і полюбив микросервисы, частина 1: Ефекти поганого коду

Преамбула
У цій серії постів я збираюся обговорити різні переваги микросервисов як архітектурного патерну. Я постараюся охопити аспекти, які або не обговорюються в мережі зовсім або обговорюються, але недостатньо глибоко.

Всі патерни розробки, як правило, мають свої плюси і мінуси. Таким чином, переваги часто носять суб'єктивний характер і розробнику слід вибирати підходящі моделі в залежності від умов контексту.

Я постараюся виділити об'єктивні або майже-об'єктивні плюси — переваги, які дадуть позитивний ефект будь-якому розробнику незалежно від мови програмування, розміру команди або дієти. Перша стаття присвячена вартості погано написаного коду – ми порівняємо ефекти впливу такого коду на монолітні програми і на микросервисы.

Читати далі →

Візуалізація інтеграційних додатків

image

З тих пір, як я почав виконувати обов'язки системного архітектора, мені частіше доводиться малювати прямокутники і стрілки, ніж писати програмний код. З цим можна було б боротися, наприклад, безсонними ночами брати участь у проектах з відкритим вихідним кодом, створювати підтвердження обґрунтованості концепції і демонстраційний код, але і там теж потрібно малювати прямокутники, щоб продемонструвати архітектуру. Ця стаття присвячена візуалізації обміну повідомленнями в розподілених системах, сервіс-орієнтованої архітектури (SOA) і микросервисным додатками при використанні методології розробки agile (цей термін втратив своє значення, але більш підходящого в даному випадку немає).

Читати далі →

За підсумками Rambler.iOS #8

Splash Screen
Два тижні тому, 5 жовтня, відбулася восьма зустріч Rambler.iOS, яку ми попередньо анонсували на Хабре. Цього разу основний акцент був зроблений на контенті самої конференції — ми підготували чотири крутих доповіді, в тому числі один від іноземного доповідача.

Читати далі →

Проектування Web API в 7 кроків

7stepsРозробка веб API це щось більше ніж просто URL, HTTP статус-коди, заголовки і зміст запиту. Процес проектування — те, як буде виглядати і сприйматися ваш API — дуже важливий і є хорошою інвестицією в успіх вашої справи. Ця стаття стисло описує методологію для проектування API з опорою на переваги веба і протоколу HTTP, зокрема. Але не варто думати, що це застосовно тільки для HTTP. Якщо з якоїсь причини вам необхідно реалізувати роботу ваших сервісів використовуючи WebSockets, XMPP, MQTT і так далі, застосовуючи більшу частину всіх рекомендацій ви отримаєте практично той же API, який буде добре працювати. До того ж отриманий API дозволить легше розробити і підтримувати роботу поверх декількох протоколів.

Хороший дизайн зачіпає URL, статус-коди, заголовки і зміст запиту
Зазвичай керівництва по проектуванню Web API фокусуються на загальних концепціях: як проектувати URL, як правильно використовувати HTTP статус-коди, методи, що передавати в заголовках і як спроектувати дизайн вмісту, яке представлене сериализованными даними або графом об'єктів. Це все дуже важливі деталі реалізації, але не настільки в сенсі загального проектування API. Проектування API — це те, як сама суть сервісу буде описана і представлена, то що вносить значний внесок в успіх і зручність використання Web API.

Хороший процес проектування або методологія надають набір узгоджених і відтворюваних кроків для створення компонентів сервісів, які будуть доступні у вигляді Web API. Це означає, що така прозора методологія може бути використана розробниками, дизайнерами та архітекторами для координації своїх дій з реалізації. Використана методологія так само може уточняться з часом по мірі того, як поліпшується і автоматизується процес без шкоди для деталей методології. Насправді, деталі реалізації можуть змінюватися (наприклад, платформа, ОС, фреймворки і стиль UI) незалежно від процесу проектування, коли ці дві активності повністю розділені і задокументовані.

Читати далі →

Управління API і SOA

Досягнення початкового успіху для Сервіс-орієнтованої Архітектури (Service Oriented Architecture, SOA) визначається:
  • створенням слабосвязанних сполук «споживач-постачальник»,
  • дотримання принципу поділу відповідальності між споживачем і постачальником,
  • публікація набору повторно використовуються, загальних сервісів
  • і забезпечення того, щоб споживачі прийняли і стали використовувати сервіс.
Безліч команд розробників створюють і використовують сервіси, але досі йде болісний підбір архітектури, при якій сервіси будуть широко використані, з потенціалом для повторного використання внутрішніми командами розробки. Замість створення узгодженої сервісної архітектури та демонстрації множинного використання одних і тих же сервісів, розробники знову і знову не навмисно створюють «Просто Набір Веб Сервісів» (Just a Bunch of Web Services (JBOWS)) або Просто Набір REST Сервісів» (Just a Bunch of REST Services (JBORS)).

Просте додаток найчастіше працює з певним сервісом і спагетті-мережею кінцевих точок, постачальників даних цього сервісу, які переплетені зв'язками один-до-одного. Багато команд в цьому випадку сходяться на думці що фокус на SOA і REST не те щоб допомагав у вирішенні питань гнучкості рішень. Швидше просто відбувається підміна набору IT інструментів, форматів повідомлень і протоколів.

Управління SOA, API, та додатком може стати мостом між цими концепціями і поліпшити архітектурну узгодженість всього рішення.

Сервіси, API та архітектура
Коли ви будете вирішувати, що використовувати як кращі практики для сервіс-орієнтованої архітектури, визначати дизайн RESTful сервісів, коли будете формувати план по управлінню ними, чітко визначте, як ваші сервіси і API разом будуть укладатися в загальну архітектурну картину.

Читати далі →

Impress Application Server простими словами

Це не перша вступна стаття про Impress на Хабре, але за останній рік я отримав багато питань і придбав деякий досвід у поясненні архітектури і філософії цього сервера додатків і, сподіваюся, став краще розуміти проблеми і завдання розробників, початківців його освоєння. Та й у самому сервері відбулося досить змін, щоб назріла актуальність абсолютно нової вступної статті.

Impress Application Server (IAS) — це сервер додатків для Node.js з альтернативної архітектурою і філософією, не схожий на мейнстрім розробки під нодой і покликаний спростити і автоматизувати широке коло повторюваних типових завдань, підняти рівень абстракції прикладного коду, задати рамки і структуру програм, оптимізувати продуктивність коду, так і продуктивність розробників. IAS покриває зараз тільки серверні завдання, але робить це комплексно, наприклад, можна об'єднати на одному порту API, веб-сокети, стрімінг, статику, Server-Sent Events, проксіювання та URL-реврайтінг, обслуговувати кілька доменів і кілька додатків, як на одному сервері, так і на групі серверів, що працюють у зв'язці, як одне ціле, як один сервер додатків.

Читати далі →

Запрошуємо на Moscow Django Meetup 31 липня

    
Якщо ви ще не поїхали у відпустку (або вже повернулися), то хочемо запросити вас 31 липня на черговий, вже 21-й за рахунком, Moscow Django Meetup. Як звичайно, формат зустрічі увазі невелику програму виступів. Всього буде дві доповіді:
 
     
  1. Використання сервіс-орієнтованої архітектури (SOA) для побудови складних веб-проектів.
  2.  
  3. Про шкоду апріорних' форм' познанiя Вь прімененiі Кь содержанiю веб-сторінок на прiмерах' Django і Яндекс.Метрики.
  4.  

Читати далі →