Кофе-брейк #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, если вам нужно простое решение.