Кава-брейк #31. 9 помилок у кар'єрі, яких повинен уникати кожен розробник. Чому архітектура REST API набирає популярності?

9 помилок у кар'єрі, яких повинен уникати кожен розробник програмного забезпечення

Джерело: Infoworld Давайте по-чесному. Деякі з вас почали вивчати програмування, тому що ви чи ваші батьки вважали, що так вам буде легше заробити багато грошей. Ви не надто захоплювалися в школі комп'ютерами, і вам не дуже подобалася розробка програмного забезпечення. Якщо це так, це говорить про те, що ви завжди будете посереднім програмістом. Так, ви зароблятимете хороші гроші, тому що наша галузь цьому сприяє, але ця стаття не для вас. Але якщо вас у дитинстві карали за те, що ви розбирали електроніку, щоб зрозуміти як вона працює... Якщо ви сиділи опівночі в інтернеті, щоб дізнатися, як створити відеогру... Якщо ви витрачали дорогоцінний вільний час на вивчення того, про що вас ніхто не просив... ця стаття для вас. Вам потрібно змінити сприйняття своєї кар'єри. Ви більше не пишете код заради інтересу: ви робите це за гроші. Заради інтересу ви можете підтримувати свої проекти. Але, будь ласка, переконайтеся, що вам, принаймні, подобається ваша основна робота. Якщо ні, знайдіть краще місце, якщо це можливо. Ваша мета повинна полягати в тому, щоб відкрити свій пенсійний фонд, покласти в нього всі долари, що є після сплати податків, купити будинок, машину і робити те, що ви хочете. Можливо, мандрувати. Паралельно вам потрібно думати про свою кар'єру, а не лише поточну роботу. Для цього вам потрібно уникнути дев'яти підводних каменів, про які зараз йтиметься.

Підводний камінь № 1: не залишайтеся надто довго в одній технології

Я зрозумів. Вам подобається C # або Java або JavaScript, Python або Cobol. Але більшість технологій мають життєвий цикл впровадження, піку, аутсорсингу, ніші та неможливості використання. Тобто, якби ви знали Cobol у 1980-х, це було б круто. Але сьогодні програмісти на Cobol не заробляють багато грошей. Тобто, суть у тому, що знаючи лише одну мову програмування, вам рано чи пізно доведеться скоротити свої витрати, переїхати в місто дешевше, тому що заробляти ви менше.

Підводний камінь № 2: не будьте айтішником-монополістом

Вам потрібно хеджувати свої інвестиції. Може здатися, що просто потрібно стати експертом у тих технологіях, які зараз домінують на ринку. Але тоді ви зіткнетеся з великою конкуренцією. Крім того, коли попит на вашу спеціалізацію знизиться, у вас уже має бути готовий план виходу. Наприклад, я був фахівцем із C++, коли з'явилася Java. Я вивчив Java. Кілька років тому всі почали говорити про Ruby як про нову зірку серед мов програмування. А ще в якийсь момент здавалося, що Perl досягне того ж рівня, що й Java. Прогнозувати майбутнє складно, тому хеджування ваших ставок – найбезпечніший спосіб забезпечити актуальність на ринку праці.

Підводний камінь №3: не тримайтеся за забаганки

Рано чи пізно магія зникає. Люди не будуть наймати розробників Groovy чи Ruby. Якщо ваш бос дозволить вам використовувати застарілі мови в проекті, це буде або тому, що йому все одно, або він просто не обізнаний. Будь-що, вивчайте і використовуйте новітні технології. Будьте готові стати одним із перших, хто дізнається про них та станьте експертом у цьому. З іншого боку, будьте готові до крутих змін, якщо попит на вашу спеціалізацію знижується. Завжди є інші нові технології, в які можна закохатися, будь то мова чи база даних.

Підводний камінь №4: алергія на правила

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

Підводний камінь №5: незацікавленість у бізнесі

"Я просто розробник, я не цікавлюся бізнесом". Це шлях у нікуди. Вам потрібно навчитися рахувати. У компанії справи йдуть добре? Які її основні бізнес-завдання? Які її найважливіші проекти? Як технології чи програмне забезпечення допомагають досягти їх? Як ваша компанія вписується у загальну галузь? Якщо ви не знаєте відповіді на ці питання, ви працюватимете над несуттєвими проектами для несуттєвих людей у ​​несуттєвих компаніях за відносно несуттєву суму грошей.

Підводний камінь №6: менталітет "профспілкової солідарності"

Коли я був молодим, одним із моїх колег була людина, яка майже все розраховувала на шість місяців уперед. Він зробив помилку, вирушивши у відпустку, тому я закінчив весь проект за два тижні, але залишив йому один шматок для роботи. Я очікував, що він буде радий цьому. Виявилось, що він не зрадів. Закінчилося тим, що він використав будь-яку можливість, щоб мене звільнабо. Це стало його головною метою. Він навіть скаржився на мене нашому новому директорові. Звісно, ​​я зробив всю свою роботу. Я був новатором. Я завжди знаходив нові способи робити речі краще та швидше і вирішувати проблеми. Він вийшов на пенсію незабаром після того, як я пішов на інше місце. Кілька разів я бачив його в кафе, і ми вдавали, що не знаємо одне одного. Це був не останній випадок, коли я стикався з подібним методом роботи: «Виконуйте все повільно, або буде гірше». Моя порада: пишіть правильний код, але будьте готові зустрітися з несподіванками. Якщо проблему вирішити не вдасться, йдіть, грюкнувши дверима: ваша компанія не єдина на ринку.

Підводний камінь №7: не знаєте собі ціну

"Я тут не заради грошей". Ну, тоді займайтеся хобі. Не ходіть щодня на роботу, думаючи про наступну зарплатню. Вам також не варто ходити на роботу, якщо ви заробляєте на 50% менше, ніж усі інші. Знайте собі ціну та не применшуйте її.

Підводний камінь №8: ставитись до своєї роботи як до роботи

"Це просто робота". Ні, це крок у вашій кар'єрі. Ви не будете на цій роботі вічно. Отже, що ви можете дізнатися тут? Яким буде ваш наступний крок? Де ви зрештою хочете опинитися? Як ця робота допоможе дістатися цієї мети? Підвищуйте обізнаність у навколишній обстановці. Це послужить гарною службою в довгостроковій перспективі. Це не просто робота, це мандрівка.

Підводний камінь № 9: думаєте, що це лише гроші

Продавці люблять говорити: "Я працюю, якщо кинути монетку". Так, але якщо ви не працюєте у продажах, то ніхто не хоче працювати з кимось, хто на цій роботі лише заради грошей. Я знаю, що хочу працювати тільки з тією людиною, яка відповідально ставиться до роботи. А ви? З іншого боку, не треба бути нестерпно відповідальним. Якщо ви по-справжньому стурбовані лише вічною суперечкою “таби чи прогалини”, можливо, вам потрібно попити заспокійливе.

Чому архітектура REST API набирає популярності?

Джерело: DZone Миттєвий зв'язок - це дивовижна річ. Ми всі звикли до того, що можемо вмить зв'язатися з будь-якою точкою земної кулі. Зі стаціонарних комп'ютерів або мобільних пристроїв ми можемо купувати, розміщувати, прикріплювати і вибирати будь-що і будь-де. Ми пов'язані один з одним та з усім світом, як ніколи раніше. Але як це відбувається? Як дані потрапляють до нас звідти? Пристрої та програми з'єднуються один з одним за допомогою інтерфейсу прикладного програмування, або API. Це саме той двигун "під капотом". Він завжди знаходиться за кадром, і ми звикли вважати його чимось звичайним, але саме API створює всю інтерактивність, на яку ми розраховуємо.

Що таке API?

Просто кажучи, API — це месенджер, який приймає запити, повідомляє системі, що ви хочете зробити, а потім повертає вам відповідь. Для наочного прикладу представте API офіціантом у ресторані. Уявіть, що ви сидите за столом, тримаючи в руках меню, а кухня - це частина системи, яка підготує ваше замовлення. API - це ланка, яка передасть ваше замовлення на кухню і доставить їжу до столу.

Давайте візьмемо реальний приклад:

Ми всі знайомі з процесом пошуку авіаквитків онлайн та знаємо, що для бронювання рейсу нам доведеться взаємодіяти з сайтом авіакомпанії. Ви отримуєте доступ до їх бази даних, щоб дізнатися, чи є вільні місця на певну дату і які витрати на вас чекають на підставі ваших вимог до перельоту. Але що якщо ви не використовуєте сайт авіакомпанії, який має прямий доступ до інформації? Що, якщо ви використовуєте онлайн-сервіс замовлення квитків, який збирає інформацію з різних авіакомпаній? Сервіс взаємодіє з API авіакомпанії, де API — це інтерфейс, який, як і наш послужливий офіціант, запитує у онлайн-служби інформацію про бронювання місць та вибір переваг пасажира щодо харчування чи багажу. Потім API приймає відповідь авіакомпанії та доставляє її назад до онлайн-сервісу, який відображає інформацію для пасажира. Приблизно такий самий процес відбувається між усіма іншими додатками, даними та пристроями. Всі вони мають API-інтерфейси, які дозволяють комп'ютерам керувати ними, і це зрештою створює зв'язок.

Які типи API-інтерфейсів?

Архітектуру API можна реалізувати двома основними способами: одним із цих способів реалізації передачі є SOAP, а іншим основним способом — REST. Ми вже встановабо, що API-інтерфейси забезпечують зв'язок між двома програмами. А зараз ми дізнаємося, як саме SOAP та REST вписуються в комунікаційну архітектуру.

SOAP API

SOAP (Simple Object Access Protocol) — це веб-служба, що відповідає специфікаціям з певними принципами зв'язку, які встановлюються між центральним органом W3C і базовим набором специфікацій. Цей набір включає:

• SOAP
• WSDL
• UDDI

SOAP — це протокол, який визначає, як дві програми взаємодіятимуть одна з одною. Дві програми при спілкуванні один з одним повинні дотримуватися загального формату, і цей загальний формат повинен базуватися на мові XML. XML в API-інтерфейсах SOAP має відповідати стандарту SOAP Message, що складається з Envelop, Header та Body.

REST API

Це дуже важлива, але часто неправильно зрозуміла концепція веб-сервісів, тому розшифруємо, що означають REST або RESTful API. REST є веб-службою, яка ініціює зв'язок між двома програмами, використовуючи власні принципи архітектури. Архітектура REST - це архітектурний стиль, який не дотримується жодного протоколу, немає строгих специфікацій і відсутній центральний орган, який контролює специфікації. Це робить REST універсальним для використання чи створення будь-якого виду послуг. Коли ці принципи застосовуються для створення веб-сервісу, ми отримуємо RESTful web-сервіс. Тепер давайте трохи заглибимося і з'ясуємо принципи, на яких ґрунтується архітектура REST.

Єдиний інтерфейс

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

Без збереження стану

В архітектурі RESTful всі відповіді та запити, весь зв'язок між серверами не зберігають стан. Це означає, що сервер не підтримує поточний стан системи, клієнт може надіслати запит, який сам по собі завершено. І цей запит не залежить від жодного з попередніх запитів. Наприклад, якщо ви робите покупки в інтернеті і додаєте товари в кошик, сервер не підтримуватиме стан вашого кошика, тому кожного разу, коли користувач надсилає запит на сервер, він міститиме стан кошика на момент подання запиту. За відсутності збереження стану сервер не має накладних витрат на зберігання або підтримання сеансу, отже, це підвищує продуктивність веб-служби.

Можливість кешування

В останньому протоколі ми помітабо, що в архітектурі RESTful сервер не зберігає стан сеансу, все кешування відбувається на стороні клієнта. Щоразу, коли клієнт надсилає запит на сервер, сервер повертає відповідь, яка містить фактичні дані, а також інші метадані, які вказують клієнту, чи повинен він зберігати відповідь локально чи ні.

Багаторівнева система

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

Код за запитом

Це необов'язкове обмеження веб-служб RESTful, яке працює, коли користувач надсилає запит для отримання відповіді. Відповідь може запускати код на стороні клієнта. Цей принцип розширює функціональні можливості спілкування.

Чому REST API використовують все частіше?

REST здебільшого простіше у використанні, більш гнучкий, і він має ряд переваг у порівнянні з SOAP. Наприклад, не потрібні дорогі інструменти для взаємодії з будь-яким веб-сервісом. Архітектура REST простіша, її можна легко налаштувати, і вона не вимагає спеціальних навичок при створенні комунікаційної моделі. Вона ефективна у використанні, оскільки може використовувати клієнтську частину сервера для зберігання інформації, що стосується клієнта. REST використовує менші формати повідомлень та забезпечує більш швидку взаємодію, оскільки не потребує тривалої обробки. REST також ближче до інших веб-технологій, коли справа доходить до філософії дизайну.

SOAP чи REST?

Для вимог типової веб-програми SOAP часто буває зайвим. REST - це простіше рішення, яке має все необхідне, коли веб-додаток потребує API. Однак трапляються випадки, коли API-інтерфейс повинен бути трохи складнішим для виконання завдань. Наприклад, якщо API потрібний для автоматизованих запитів, для такого сценарію краще вибрати SOAP API. Простіше кажучи, вибирайте SOAP, якщо завдання велике і складне, і вибирайте REST, якщо вам потрібне просте рішення.