Почему почти все вакансии хотят RESTful API?
Имхо REST это полный остой, все нормальные чуваки должны использовать RPC.
Facebook
Twitter
LinkedIn
Володимир Корнійчук
Це, я думаю, перемога в конкурсі «як завалити співбесіду за одне речення»
Edyta Smalarz
Еще и знание каких-то языков программирования требуют, совсем обнаглели.
Олександр Мощенко
ну не знаааю. Переглядав нещодавно вакансії клінінг-менеджерів та спеціалістів з вантажоперенесень — жодних вимог до rest чи api узагалі.
Тож, думаю, варто перефразувати питання. Хай буде щось на кшталт «чи варто погромістам вчити математику?» Бо про уміння лічити, бодай, до сотні я зустрічав.
Sergiy Morenets
REST API та RESTful веб-сервіси — дуже потужна штука, якщо ними правильно користуватися.
На жаль, більшість знає поверхово їхні принципи, від того й проблеми, що люди реалізують їх по-різному.
Я навіть написав дві статті, де розповів про те, як правильно використовувати REST API:
dou.ua/forums/topic/34550
dou.ua/forums/topic/40940
Dou Dou
Манямирок с книгами и их ордерами с тупым крудом.
Victor Musienkо
Gremlin
Victor Gubin
Ну там троль філософія. Така собі провакаційна джинса, де тишком нишком якийсь Reactive Nocode фреймверк від рекламувати треба. Тут тролінг банальний, просто пряма провокація.
Victor Gubin
Як завжди найтиповіша робота, яку замовляють клієнти — це створення або підтримка (виправлення помилок і покращення) корпоративних інтернет сайтів. Інтернет магазини, логістичний софт для служб доставок, таксі, SAS програмне забезпечення наприклад для офісної роботи тощо. На цьому ринку існує глобальний технологічний тренд Server Less підхід до проектування Web застосунків. Є потреба — одразу підтримувати : декстоп, мобільні і планшет/лептоп пристрої, зменьшити навантаження на серверне обладнання щоб витримувати пікові навантаження. На це індустрія в лиці технологічних лідерів, відомих як MAANG відповіли саме архітектурою і технологічним стеком Sever less. Claud computing і контейнеризація, microservice architecture (Amazon arch 6) — back end, SPA — для Frontend (Angular, React/Redux, Vue), CSS фреймверки типу Bootstrap, SASS/LeSS і нативні мобільні застосунки (бо вони навідміну від сайтів вміють давати нотіфікації, що є дуже впливовим механізмом маркетингу) Комунікація між клієнт-сервером і між сервісами зазвичай робиться через RESTful підхід. Тому власне на це і є попит на ринку. RPC вже був з ним багато де більше проблем аніж рішень. Головна з котрих JavaScript для браузера дуже ускладнюється технологічно, JavaScript любить JSON і не любить різні IDL чи WSDL. Відстій не відстій то юнацький максималізм, дивлячись для чого. Десь одне підійде краще, десь іньше.
Sergey Lysak
Задум RPC був у безшовності виклику процедур у коді.
Задум REST — нам байдуже яка імлементація, ми працюємо з колекціями данних, об’єктів, які у загальному випадку можуть і не мати відповідних структур данних у програмному коді.
Однаковий транспортний рівень так, зробить його імплементацію схожою для обох підходів.
Android
Да все отстой, после внимательного изучения. Наша задача — слепить различный отстой в конфетку.
Если конкретно про RESTful — это просто популярно, другого объяснения не вижу. Я видел в своей жизни одно реально работающее как надо REST-API (всмысле оно реально было REST и оно реально было удобно и логично, а не через жопу, как работает абсолютно любое другое REST-API из виденных мной — а видел я слишком много). Это, внимание, AWS S3.
Я на последнем проекте (как тех-лид) запретил произносить эту аббревиатуру и мы сделали, в принципе, RPC through HTTP, выкинули нафиг все статус-коды кроме 200, 400, 401 и 403, сделали контракт, что в response-body всегда передается ответ в заранее определенном формате с кодом ответа, текстовымы полями error_code+error_text (если надо) и выделенным полем для, собвственно, результата вызова. Если бы пришлось все это одевать в REST — я бы уже свихулся. Никаких идиотских «PUT users», «POST feed/posts», «PUT feed/posts/{id}» и прочего говна, вместо него «POST users/updateMyProfile», «POST feed/createPost», «POST feed/updatePost». Выглядит как обычный интерфейс класса, только вызывается через HTTP. Написали простую доку с path & request/response schema.
выкинули нафиг все статус-коды кроме 200, 400, 401 и 403
сам викидываю. потому что на фронтенде все равно получается несколько слоев, а эти коды обрабатываются в самом нижнем, транспортном. и если это не указанные выше — то нужно и можно сделать что-то осмысленное — на более высоких слоях. значит — все равно туда прокидывать «error_code+error_text»
В общем случае мы имеем два больших класса ошибок:
транспортные — дальнейшая обработка ответа не имеет смысла, потому что например 403. или 500
ошибки бизнес-логики, куда входят и ошибки неконсистентной работы с БД
Второй класс ошибок отражать HTTP статусами не логично, слишком низкоуровнево. Потому что эти ошибки возникнут и если мы перейдем скажем веб-сокеты, то есть они не зависят от того — каким образом мы получили ответ на наш запрос.
«POST users/updateMyProfile», «POST feed/createPost», «POST feed/updatePost».
...Выглядит как обычный интерфейс класса, только вызывается через HTTP
это вроде как RPC у вас получился :)
но правда что:
Да все отстой, после внимательного изучения
Dmitriy Mozgovoy
PUT feed/posts/{id}
POST feed/updatePost
Разницы в общем то никакой.
Если бы пришлось все это одевать в REST — я бы уже свихулся.
Одевать это надо один раз когда делаешь слой доступа к контроллерам. Если хорошо проработать этот вопрос, то контроллеру будет все ровно через какой адаптер к нему стучатся — он то будет работать с запросами в своем внутреннем представлении.
Вобщемто разніца є, і вона велика.
Тема срачна, тому пропоную одразу кидатись защекойнами.
«POST users/updateMyProfile», «POST feed/createPost», "POST feed/updatePost"
Написав гівнокостилів і радий, ще й личкою техліда помахав.
Іди хочаб почитай в чому різниця між рпц і рестом, неуч.
А потім викинь своє подєліє.
Oleksandr Bereziuk
“POST users/updateMyProfile”, “POST feed/createPost”, “POST feed/updatePost”
Поздравляю, вы только что реинкарнировали SOAP-approach. Правда, без wsdl, но то такое
от! все думав і думав, на яке гівно з похмурого минулого воно схоже. Точна, це гівно-соап
schwarzlichtbezirk
выкинули нафиг все статус-коды кроме 200, 400, 401 и 403, сделали контракт, что в response-body всегда передается ответ в заранее определенном формате с кодом ответа
То есть, статус-код 500 у вас в дизайне API не предусмотрен? Да вы оптимист, однако!
Miroslav Grabinskiy
Ярослав Характерник
TypeScript як два роки тому був експериментальним то й зараз такий. Попереносили й стабілізували тільки те, що дотичне до їх технологій.
Invisible insider
Почему почти все вакансии хотят English?
Имхо English это полный остой, все нормальные чуваки должны использовать Hindi.
Краще вже мову де написання співпадає з читанням
В хінді все співпадає, проблеми нема.
а прочітать те шо співпадає :) ?
Писемність вчиться за тиждень без напрягу.
(Про розуміння мови ніхто не казав;))
Volodymyr Ostapiv
Нормальні чуваки і використовують хінді між собою, на інгліш то вони тільки з вами і замовником :)
Bot Bot
Взагалі RPC це більш про те що наприклад ви віддаєте перевагу визову процедурі яка знає як модифікувати данні, а не просто вставити ці нові данні. це більш актуально наприклад коли ви синхронізуєте дві струтури данних, і от в одних випадках вам краще просто вставляти нові данні з лідер структури на фоловер структуру (це база даних, або ж просто ін меморі кєш, тощо), а в інших випадках (наприклад для 100 000 записів додати +380 для телефону, просто зробити формат телефону міжнародним) вам краще процедуру визвати яка скаже фоловеру просто змини данні ось так як в цій продцедурі написано, а не робити 100 000 апдейтів. Усе це залежить дуже від конекретних кейсів та аплікейшенів. Тобто рінзі підходи для ріних кейсів, але зовсім не є ахрітиктурними паттеранми.
Тобто ти обираєш відправляти команди, а не голі данні. Звісно це не замінить тих моментів коли данні треба просто додавати.
Нахіба воно у уєбі, та ще й у порівнянні з рест, для того щоб ганяти форми\модельки туди сюди я до сих пір не роздуплив.
Ну окрім того що написав ніжче — базворд для звиздоболів.
Взагалі мені це нагадало анекдот для накурених — «чим відрізняеться танк від помідора? помідор червоний, а в танка люк у верх відкривається.»
Я думал, что RPC это когда ты дергаешь соседний сервер/сервис, не? Не пойму при чем тут фоловеры и модификация данных.
Это он с валидаторами перепутал.
Bot Bot
який валідатор у твітері?
REST это representional _state_ transfer.
Теперь представь себе веб-страницу, например, банка. Ты отправляешь перевод в 1000 гривен со своей карточки на, например, карточку жены.
Варианты сделать это через веб:
1. Древняя классика: какой-нибудь /transfer.cgi, получающий заполненную форму (карточка назначения, сумма). (Игнорируем тут тему XSRF и прочая.) Выполняется, отдаёт страницу /transfer_success.cgi, /transfer_failure.cgi, или что-то подобное.
2. Запрос AJAX/аналогом: по сути это RPC. Уходит запрос в api.bank.com/transfer с JSON в котором сумма и карточка куда (может быть карточка откуда), авторизация чем тут принято (например, JWT). Скрипт получает ответ и обновляет страницу соответствующе — рисует «не шмогла» или «шмогла»... если второй фактор — рисует «в ожидании второго фактора» и подписывается через websocket на нотификацию о результате авторизации вторым фактором... куча вариантов. Всё время выполнения операции перевода (трансфера, переказа), фактически, выполняется инициированная клиентом процедура, внутри которой — ха ха — может выполняться инициированная сервером процедура «получить от клиента значение второго фактора». Чуть сложно, но понятно.
3. REST... и вот тут возникают вопросы. КАК _это_ уложить в REST? Можно, конечно, создать объект в коллекции «ожидающие запросы данного пользователя», какая-нибудь /outstanding_requests. PUT запрос со своим сгенерённым id или POST с тем, чтобы оно само сгенерировало. Ну ладно, сработает. Хотя уже костыльно: такой POST, например, не кэшируется, а кэшируемость считается одним из основных преимуществ REST.
И вообще, конечно, можно любое взаимодействие перевести хоть на вложенный IP стек, хоть на email, но нафига делать троллейбус из буханки?
А дальше? Ты послал запрос, оно создало. Как без задержки получить результат операции, или то же предупреждение про 2FA? Поллить состояние у сервера? Если ты подпишешься на обновления, то это уже не совсем REST. Если, как в варианте 2, сервер сходит к клиенту (браузеру) за данными, это уже тоже не REST.
Вот и получается:
Я думал, что RPC это когда ты дергаешь соседний сервер/сервис, не?
НЕ. RPC между клиентом и сервером — в полный рост.
Это только один пример был, а их можно нагенерировать 100500.
REST нужен там, где он адекватен. Но там он действительно эффективен.
Не, жены нет, ничего не понятно. Все три опции концептуально делают то же самое — гоняют данные через HTTP от клиента к серверу.
Все три опции концептуально делают то же самое — гоняют данные через HTTP от клиента к серверу.
«Но есть нюанс» ©
и этот нюанс очень существенно влияет на подходы.
Oleksandr Merkulov
А фиг его знает. Вот читаю
en.wikipedia.org/...entational_state_transfer
Все подходит к ajax. Ну если правильно приготовлено. Даже Cacheability как define themselves as either cacheable or *non-cacheable*
Собственно всегда считал, что jquery/ajax — это REST. Cacheable часть которая страничка, все ок.
Может, как то так? www.quora.com/...hip-between-REST-and-AJAX
Теоретически ресту должно быть вообще фиолетово на аякс, хттп и жеквери. Рест должен работать даже поверх голубиной почты. И строго говоря, рест это то что написано в дисере филдинга. Любая другая информация о рест выдуманный треш.
Все подходит к ajax. Ну если правильно приготовлено. Даже Cacheability как define themselves as either cacheable or *non-cacheable*
Ну да — AJAX не регулирует, какие запросы бегают (по крайней мере, обычно, пока там HTTP к тому же серверу), и пытаться вложиться в REST или нет — дело строителя конкретного сайта.
Собственно всегда считал, что jquery/ajax — это REST. Cacheable часть которая страничка, все ок.
Не обязательно. Можно делать более свободный RPC любого вида, если за RPC принимать отправку запроса в JSON/XML неважно какого и обработку ответа такого же.
Но попытка вложиться в рамки REST при этом имеет полезные последствия в двух аспектах, 1) кэширование, где возможно, и 2) структурирование мышления вокруг объектов — данных (тип и конкретный экземпляр), что чаще помогает, нежели мешает.
Может, как то так?
Ой, только не quora. На этой помойке что-то полезное найти и не утонуть — иногда получается... но редко и не в этом случае.
Но попытка вложиться в рамки REST при этом имеет полезные последствия в двух аспектах, 1) кэширование, где возможно, и 2) структурирование мышления вокруг объектов — данных (тип и конкретный экземпляр), что чаще помогает, нежели мешает.
Большой плюс REST API (важно: грамотно задизайненных) — ты плюс-минус сразу представляешь, что и как надо вызывать как клиенту чтобы добиться ожидаемого результата.
Условная пара POST /orders и PUT /orders — вещь лаконичная и самодокументированная, а вот createOrder и updateOrder — не настолько. Не говоря уже о том, что вместо createOrder/updateOrder имена могут быть и insertOrder/replaceOrder и вообще, есть производная от вкусов девелоперов, которые могут быть весьма специфичны )
а ты его дергаешь зачем свой сервис, не для модификации ли данных? ))) не важно база данных это или апликейшен. база данных это тоже апилкейшен который хранит, возвращает и модифицирует данные.
Ну это просто — чтобы получить или отдать что-нибудь. А зачем ещё что-нибудь можно дергать?
Например модфикация данных, ты просто тупо вставишь апдейты или просто вызовешь функцию на удаленном приложении\сервере для модифицаии данных?
Вставить данные — запустить SQL?
Если мы говорим про RPC, значит я дергну функцию и мне все равно что и как она делает под капотом. А какие еще варианты есть?
Вставить данные — запустить SQL?
из браузера? :-)
Тому що це ще один базворд, як пишуть що потрібен JSON. Або як пишуть що потрібні знання клауду, а у самих на віртуалках клауда моноліти хостятся і називають це міграцією ))))
Я вже сумую за звичайним монолітом
Ти шо?! А як же лямбди, черги, кубернетіс, 100500 репозиторіїв та скрпиптів в кожному проєкті щоб підняти хєллоу ворлд сервіс?
В нас зараз 100 користувачів, але завтра точно-точно буде 100 000 то давайте півроку писати систему яку буде масштабуватись до 100 000 000
Jan Haring
та на black friday вручну пiднiмають бiльше контейнерiв (один фiнтех однорогий)
Alexandr Gavriluk
Имхо REST это полный остой, все нормальные чуваки должны использовать RPC.
А между ними концептуальная разница есть? И то и то реинкарнация архитектуры терминал-мейнфрейм.
є один ньюанс: RPC — віддалені виклики процедур
Хіба «віддай мені значення обʼєкта номер 1234 типу moo» це не виклик процедури?
формально, ні, а якщо зроби виклик get_obj_1234(), тоді так
Мабуть таки get_moo(1234) :)
Але саме тут різниця чисто в стилі запису. Всі обмеження у проктрустово ліжко REST уже зроблені десь назовні...
RPC — віддалені виклики процедур
І це вигадали ще за часів COM компонентів, а може ще й до них.
Перша значна версія RPC була в OS/360 (1960ті). Звичайно, в фірмовому стилі IBM:)
В 1980х вже було декілька одночасно існуючих форм: ONC (Sun RPC), UUCP... З наступного DCE весь світ спіонерів UUID (GUID) ідентифікатори.
Проміжні ступені, як DECnet, не згадував, там багато хитрого, але довго вдивлятись у деталі...
REST это RPC с ограничением что запросы ходят через HTTP без состояния, возможно с использованием разных HTTP методов, и возможно идентификацией ресурса через URL.
Вообще-то состояние это довольно условный параметр, на REST тоже можно работать в режиме логического состояния с регистрацией сессии, как и с RPC можно работать в режиме без состояния.
на REST тоже можно работать в режиме логического состояния с регистрацией сессии
4 величайших извращения: хоккей на траве, балет на льду, BGP по диалапу, и REST со скрытым состоянием сессии.
(Авторизацию не учитываем.)
Ну типа RPC это вызовы процедур, а REST это манипуляция данными.
По большому счету разница только в том, можно ли клиенту доверять данные или нет. По старой концепции — нефига нельзя, а по новой — давайте вывалим клиенту таблицу в 100500 страниц когда ему нужна одна, пусть переходы в броузере делает.
А вообще просто REST это очередной стиль вызова тех же RPC и COM(former ActiveX).
Просто новое поколение не помнит, что такое было.
А gRPC — это бинарный RPC и, собственно,не особо оно от COM отличается, но модно новое слово вставить.
Единственная крутая вещь за все это время — swager/openapi. Но по факту оно нефига не работает в большинстве компаний, поскольку джуны не могут его потестировать и никому не надо проверять. Недавно месяц общалися с поддержкой мааааленького провайдера bandwidth, в результате так и не запустили даже подмножество в 5 функций из их рабочего openapi. Написали по старинке, реверс енженирингом(хелп оказался тоже с глюками).
А вообще просто REST это очередной стиль вызова тех же RPC и COM(former ActiveX).
А gRPC — это бинарный RPC и, собственно,не особо оно от COM отличается
COM тут взагалі ні до чого, бо він зав’язаний на поняттях об’єкта та інтерфейсу, а чи воно remote, чи ні — це технічне питання
Даж не знаю что вам сказать.
Я когда gRPC писал, у меня были постоянные флешбеки по курсовой COM/DCOM
там також було це?
IMyIterable * iter = NULL; unk->QueryInterface(MY_ITERABLE, &iter); ... iter->Release();(MyIterable придумано з голови)
UPD помітив помилку в коді і виправив :)
я даже не знаю что у вас тут написано.
Вы с DCOM работали? На низком уровне?
Я думаю мы у нас просто разный уровень погружения.
Итарторы тогда еще не были модной вещью. Как и джава(это ж джава или что?). Это было в районе 2000го года.
Самий типовий COM, правда, трохи низькорівневий, бо майже всі бібліотеки намагалась скрити ось ці всі Release та обгорнути QueryInterface у щось своє типізоване.
З DCOM не працював, тому не знаю
А вообще просто REST это очередной стиль вызова тех же RPC и COM(
ШТА ? REST — это вообще не про вызовы, это про ресурсы.
Но по факту оно нефига не работает в большинстве компаний,
Я бы не утверждал так безапелляционно. Лично у меня все проекты, пятый год уже в contracts-as-dependencies парадигме, когда API генерится на основании openAPI файлов
Valentin Nechayev
Для ~99% случаев работает правило:
Если вы не можете назвать преимущества ругаемой технологии по сравнению с хвалимой, ваше сравнение неадекватно. Даже если эти преимущества надо искать под микроскопом.
Ну а то, что REST имеет свои существенные преимущества, бесспорно. Так что расскажите вначале, какие они, а потом — почему именно вам они не важны.
Ну и заодно разберитесь с вопросом, до какой степени REST тоже является RPC :)
Так почему почти все вакансии хотят RESTful API?
DNA Exp
Потому что это как рынок, где все продавцы дают сдачу и принимают гривны.
Нельзя просто так прийти на этот рынок, например, с серебром.
Если вдруг прийдется торговать с сторонними продавцами, то тебе или прийдется платить гривной или отдадут сдачей гривной. Тоесть от тебя мало что зависит на этом базаре.
С другой стороны, если это твоя внутрення лавка, то ты там можешь расчитываться хоть золотом. Но поскольку REST это скорей о внешней торговле, то здесь важно не качество технологии, а сколько контрагентов ее приняли за стандарт.
Так почему почти все вакансии хотят RESTful API?
«Все» это какие?
У меня на нескольких последних проектах использовались:
— Несколько вариантов самопальных request-response полутекстовых протоколов
— F1AP, E1AP, XnAP — поверх ASN.1 PER (ой, морока особого вида)
— Thrift и gRPC
— SIP как ещё один request-response транспорт (ну обломились выделять отдельный стек)
— RADIUS в который инкапсулировались собственные взаимодействия
RESTful API тоже пробегал, но очень сбоку.
Но если у вас в задаче — взаимодействие, например, скрипта в браузере с серверным бэкендом сайта, то я не вижу, что может быть лучше RESTful API для этой задачи — с нынешними-то средствами.
Ну вот я посмотрел пару десятков Java вакансий на этом сайте и почти все хотят RESTful API. Без шуток, так и пишут.
Но если у вас в задаче — взаимодействие, например, скрипта в браузере с серверным бэкендом сайта,
То есть все эти чуваки из вакансий делают сайты?
Я вот хотел джуном куда-нибудь устроиться, но у меня нет RESTful API в кармане, я только RPC умею.
Ну вот я посмотрел пару десятков Java вакансий на этом сайте и почти все хотят RESTful API. Без шуток, так и пишут.
Значит, сейчас вакансии видны только очень специализированные.
То есть все эти чуваки из вакансий делают сайты?
Скорее всего да.
Сайтостроение всех видов сейчас занимает около 2/3 всей IT работы.
Я вот хотел джуном куда-нибудь устроиться, но у меня нет RESTful API в кармане, я только RPC умею.
Это общая проблема поиска работы джуном. Но если выучить специфику ограничений REST, уже будет полегче.
Жалко, вот я умею Thrift/Drift/Swift, Coral и слышал про gRPC. Видать меня не возьмут.
А тупо почитати 10 сторінок про RESTful API релігія забороняє? Тим більше на джуна все що треба знати то розшифровка абревіатури ))
То есть все эти чуваки из вакансий делают сайты?
основная технология для создания пользовательских интерфейсов сейчас — Web.
да и десктопные нередко на нем же — Electron
поэтому «делают сайты». не все.
и сервисы не обязательно должны работать с интерфейсной частью приложения.
но обычно, массово — будет бекенд, и будет фронтенд на web.
Я вот хотел джуном куда-нибудь устроиться, но у меня нет RESTful API в кармане, я только RPC умею.
значит устраивайтесь там где RPC.
или изучите то что — требуется.
менять стек технологий, да даже текст вакансии под вас все равно никто не будет.
или учите, или проходите мимо. оба выбора — правильные.
Блэт, да прочти страничку на вики про рест, на собесах дальше пары вопросов никто не идет, в целом это вопросы: определение рест из той самой вики, какие методы на беке и фронте гет/пут/пост и в целом какие коды нттр есть. на этом твоя головная боль рест или рпц заканчивается.
Дальше все говнокодят как получится, или сидят на митингах и по джва часа всеми командами, лидами/архиекторами решают какие коды/названия методов для фронта, будешь гамать на телефоне или спать на мьюте, потом накидаешь как получится и забудешь эту хрень , потому что через год уйдешь на +500 через дорогу :-)
John Appleseed
Наче моя історія з попереднього проекту.
Коли папуга перестав співати — значить мітинг закінчився і можна йти давати відбій.
А потім знайшов кращий проект, де більше програмування і менше вовтузяться на мітингах із другорядними деталями.
по джва часа всеми командами, лидами/архиекторами решают какие коды/названия методов для фронта,
можна написати методичку «добрі правила погонял для rpc»
Дмитро
что может быть лучше RESTful API для этой задачи — с нынешними-то средствами
graphql лучше и удобней для обоих сторон взаимодействия в браузере и инструментарий более удобный/продвинутый и практика использования на рынке свидетельствует о том же
graphql лучше и удобней для обоих сторон взаимодействия в браузере
Фильтрация обмена может быть сделана и поверх классического REST, хоть и слегка коряво.
А если мы уходим от преимуществ REST к RESTоподобому RPC без преимуществ REST, зачем ограничиваться объектной моделью?
Я чесно говоря не знаю какие преимущества REST over Graphql.. быстрота прототипирования и простой разработки для сайтов визиток, работа не только с обьектной модель(сколько таких задач будетпри разработке браузерного приложения,
Во всех остальных случаях для барузера graphql более развитый инструмент — лучшая поддержка схемы, возможность управления загружаемого контента через сеть, готовая поддержка api federation и т.д. в rest api имплементациях все это боль не имеющая адекватной стандартизации и кучу breaking changes в разных версиях схемы вроде Open Api.
Я чесно говоря не знаю какие преимущества REST over Graphql
простота.
Во всех остальных случаях для барузера graphql более развитый инструмент
а на бекенде — ничего не надо делать, для удобства в браузере? ;)
Основное преимущество — делай как хочешь, только чтоб в парадигму укладывалося. А graphql мешает.
По факту вообще трудно найти сервис с каноническим REST- все о нем говорят, но никто не видел, ибо на практике у всех свои нюансы.
а потому что канонический REST сродни ассемблеру.
на нем муторно делать что-нить серьезное.
поэтому у всех сразу появляются аргументы запроса:
mode, fields, exclude, include, filter, with, sort, ...
с значениями — типа
exclude="rare"
sort="bySizeDiscount"
то есть не уровня данных, а уровня бизнес-логики
и сам ответ — я сразу делаю свой формат, envelope, с тремя полями
{
meta: {}
data: []
info: []
}
потому что в тех самых «20%» случаев в ответ надо вложить и что-то помимо коллекции основных объектов.
поэтому у всех сразу появляются аргументы запроса:
Да как бы они и должны быть, а то потом любители GraphQL рассказывают, что у них то есть селективные запросы и фильтры, а вот в REST нет :)
и сам ответ — я сразу делаю свой формат, envelope, с тремя полями
Кто то в теле, кто то в хедеры пихает мета инфу- зоопарк тут обширный и как по мне удобство важнее, чем вписаться на 100% в некую спецификацию.
а то потом любители GraphQL рассказывают, что у них то есть селективные запросы и фильтры, а вот в REST нет
это да, «удивительный» у них аргумент.
Берут какой-то самый убогий вариант RESTа, и начинают рассказывать о преимуществах GraphQL. Хотя на практике таким голым вариантом никто долго не пользуется. А добавить аргументы, еще и заточенные под конкретные потребности — делов то. при этом — все слои кеширования — прекрасно работают.
Вобщем любимый метод адептов чего-нить, или хейтеров(обычно это одни и те же персонажи — «религиозные фундаменталисты» и пуристы):
выдумываем уродину, «соломое чучело»
и давай рассказывать о преимуществах перед этим чучелом, или хейтить это чучело.
кто то в хедеры пихает мета инфу-
этого просто не понимаю. хеадер — это транспортный уровень. там даже паджинацию держать — сомнительно, хотя часто рекомендуют.
тест для меня простой:
а теперь давайте переведем все «на веб сокеты» — сколько переписывать придется? какие слои на фронте и беке помимо транспортного такой переход заденет?
чем вписаться на 100% в некую спецификацию
которой к тому же не было и не будет. потому что REST — это просто идея, подход, правила хорошего тона.
А спека у каждого фреймворка — своя.
А расширения — у каждого проекта свои.
Берут какой-то самый убогий вариант RESTа, и начинают рассказывать о преимуществах GraphQL. Хотя на практике таким голым вариантом никто долго не пользуется. А добавить аргументы, еще и заточенные под конкретные потребности — делов то. при этом — все слои кеширования — прекрасно работают.
REST никогда не был оптимизирован по трафику и всегда гонял лишние данные, хоть с фильтрами хоть без. И да, нормальные фильтры это не просто набор колонок в гриде, а в идеале шаблон, по которому рекурсивно проходят и собирают нужные тебе данные в иерархическом джисоне.
99% REST сервисов просто вываливают весь кусок джисона (сериализированный dto в коде), даже если из него тебе нужно всего пять полей из ста в данном контексте UI.
Максим Панченко
Я всегда думал, что преимущество graphql — это возможность получить одним запросом только те модели, которые тебе нужны и только те поля в них, которые тебе нужны, а не «мне нужен только тайтл от товара, и тайтл от категории, где сидит этот товар, так что загружу я /item/100500, посмотрю на id его категории, загружу вторым запросом /category/999», запросы которых вывалят по 50 полей, которые не только трафика много сожрут, но и обработки на сервере, помимо двойной работы для вебсервера
Это преимущество проявится в случае большого количества UI частей с очень разным функционалом, и большого количества фронент команд.
Для типичного проекта где максимум две-три команды преимущества рест будут незаметны. А вот его сложность — скажется.
Одной команде же фулстеков в 5 человек он тем более не нужен. Его возможности куда быстрее и проще реализуются кодом который учитывает функциональность, бизнес логику проекта.
Пример «select n+1» для наивно чистого REST да, верен. Поэтому на чистом ресте и не делают. А расширяют передавая аргументами отношения, и способ агрегации коллекций разного типа обьектов
Избыточный трафик, тоже быстро обрезается.
Вобщем это критика соломенного чучела
Надо было сразу написать, что я рассуждаю в рамках больших проектов, уже дающих кучу бабла/иного профита, так как спорить о пет проекте или стартапе бессмысленно — оно и понятно, надо сделать побыстрее, кое как, чтобы проверить идею/начать нанимать людей, а потом может быть перепишется
Ну это понятно. Как я, говорю на доу через одного пишут проекты с миллионном запросов в секунду, с командами в сотни программистов, и т.д.
А половина второй оставшейся половины работает в маангах.
Надо было сразу написать, что я рассуждаю в рамках больших проектов, уже дающих кучу бабла/иного профита
Ebay например? Давно не смотрел, когда они перешли?
графкл зручний тільки для хіпстерів які роблять фронт для туду аппок.
Для всього складнішого на бекенді графкл перетворюється на монстра, бо резолвить всі варіанти комбінацій вьюх стає космічно складно. В результаті все деградує.
Android
Существенное преимущество REST в том, что по нему можно задавать вопросы на собеседовании и унижать собеседника. Других не знаю.
А вообще REST — это тот самый 1%.
DNA Exp
Вот так бывает. Прийдет ктото в топик с совершенно незамутненным сознанием и с детской непосредственностью выскажет здравую мысль.
Как говорится, устами ребенка глаголит истина.
На самом деле и REST и RPC это полная шляпа.
Но высказывать такие идеи в наше время, всеравно что инквизиции рассказывать про
круглую землю. Скорей всего попадеш на какую-то галеру, доломают твое здравое сознание и будешь делать неправильно, как все. А потом и поверишь что это правильно.
ttps://dou.ua/forums/topic/35566/
Я прошу прощения, но топик dou.ua/forums/topic/35566/ не имеет никакого отношение к тексту поста в этом же топике, ни к RPC/REST.
И давно перестал иметь отношение?
double
Бо REST як JSON, він скрізь як непомітний ніндзя, а RPC це якісь фріки бекенду))
Бо REST римується з BEST.
Бо REST натякає, що скоро робочий день скінчиться і можна буде сидіти на краю якоїсь водойми :)
ТЗ
тут треба уточнити позицію.
писати сервіси що їх роблять може й не всім треба
а зібрати інфу якусь в джейсоні може й треба
То есть вы хотите сказать, что нынче любой GET/POST + JSON гордо называют REST сервисом?
Прошаренные люди читают Content-Type, и парсят через соответствующий парсер, то есть json, xml, yaml. Дальше читают Accept, и пишут в том, что поддерживается. Либо json, если ничего не указано.
Да. А почему нет?
вы просто добавляете ремарочку где-то во внутренних документах что такой-то пункт REST архитектуры вы неиспользуете, потому, что...
а через полгода все про нее забывают и гордо именуют ваше поделие REST API
Забейте. Тут как с обьектным программированием. Все понимают, что шляпа, половина обьектов по сути просто папочки для функций без внутреннего состояния, но все равно у вас гордо поименованый обьектно-ориентированный подход и приложение.
Це, я думаю, перемога в конкурсі «як завалити співбесіду за одне речення»
Тому, що коли клієнт в кав’ярні просить каву і тістечко, йому не повинні відповідати «пиво і таранька кращі, це всі нормальні чуваки знають»
Извините, не понял аналогию в контексте собеседования.
Нихрена ты не понял. В вакансиях пишет бред и гору мусора с потолка. Твое дело отправлять резюме на позицию и все.
Сінйори нічого не відсилають, поки їх не попросять хрю
То есть вот тут не надо 8+ лет опыта с Java 8 jobs.dou.ua/.../42958/?from=applications и можно к ним отправлять резюму без 8 лет?
Required skills:— 8+ years in experience with Java 8+, Spring: Boot, MVC, Data
— Experience with Docker
— Experience with build system — Maven
— OOP, Design Patterns, TDD
— MySQL, PostgreSQL
— Good knowledge of JavaScript, HTML, CSS3
— Experience with vue.js or React will be a plus;
— English — Intermediate or higher level;
чекати коли годинник покаже рівно вісім років досвіду :)
Интересно, что Java 8 зарелизили в 2014. Четко 8 лет назад,
Думаю, рік роботи в умовах активної фази бойових дій подавати за два.
Надо просто к 5 годам опыта на проекте добавить три паралельно на своем пет. Будет 8 всего в джаве, ну что вы.
То есть вот тут не надо 8+ лет опыта с Java 8 jobs.dou.ua/.../42958/?from=applications и можно к ним отправлять резюму без 8 лет?
Бинго. Даже 3 лет возможно хватит а 2/3 заявленых баззвордов даже не будет на проекте использоваться. Перестань заморачиваться дурацкими рефлексиями.
Жуть какая. А зачем же тогда писать такие требование? Они же отпугивают кандидатов такими требованиями, не?
А зачем же тогда писать такие требование?
Это вообще вопрос философский. Можно всё это смести в кучу и выбросить, и писать код на Go, и всё будет отлично.
А кому нужны такие пугливые кандидаты :)
Первичный отсев, без затрат и секунды времени.
Это и так проблема — большинство откликающихся на вакансию — не годятся для работы.
Например они не понимают почему рестфул, а не эрписи. Вот и здорово что не понимающий пройдёт мимо :)
Например они не понимают почему рестфул, а не эрписи. Вот и здорово что не понимающий пройдёт мимо :)
Рестфул потому что сайты-визитки делают, правильно? И вообще, как кто-то понимает почему рестфул, если он/она не знает какая именно проблема решается?
Просматривая вакансии я заметил, что чем больше ЗП в вакансии, тем реже упоминается рестфул и больше RPC.
сайты визитки делают сейчас статическими. т.е. там вообще нет бекенда. если вручную. либо накликивают в генераторах сайтов, или конвертаторах из фигмы.
да и раньше, их делали без бекенда как такового — на пхп например.
И вообще, как кто-то понимает почему рестфул
понимаете в чем дело — «рестфулу» не один год.
и на всех основных языках мира — в инете разной степени детальности за годы — полно материала.
соответственно — если чел спрашивает — «а почему рестфул » - значит пусть идет себе дальше.
и так — многие другие технологии в вакансиях появляются, из которых, как правильно заметили — хорошо если половина будет в реальной работе :)
дргугими словами:
это два вообще не связаных вопроса:
чем рестфул лучше/хуже чем Х
почему в вакансиях массово пишут что требуется рестфул
*рестфул, если не поняли — можно заменить почти на какое угодно название
Просматривая вакансии я заметил, что чем больше ЗП в вакансии, тем реже упоминается рестфул и больше RPC.
ну вот видите как замечательно — вы сразу понимаете куда идти, по описанию вакансии.
соответственно — если чел спрашивает — «а почему рестфул » - значит пусть идет себе дальше.
Как глупо выходит, не находите?
Когда я работал с чуваком придумавшим и запустившим AWS S3, он сказал что самые простые и, казалось бы, глупые вопросы, с казалось бы явным ответом, зачастую являются фундаментальными.
он сказал что самые простые и, казалось бы, глупые вопросы, с казалось бы явным ответом, зачастую являются фундаментальными.
Так ты не задал фундаментальный вопрос. Твой вопрос звучит примерно, почему все ездят на красных жигулях, а не на синих жигулях с спойлером. А правильный фундаментальный вопрос должен звучать, почему мы вообще ездим на жигулях.
Как глупо выходит, не находите?
почему глупо?
уровень человека сильнее раскрывается в вопросах которые он ставит, чем в ответах.
если чел не понимает «почему рестфул» — то зачем рисковать такого брать, когда есть достаточно тех кто понимает.
зачастую являются фундаментальными.
джунов задающих такие вопросы — давно полно.
только «джуны никому не нужны» — как я говорю уже лет 5 :) а может и больше.
вопрос же о рестфул не глупый. и не фундментальный.
просто вызывает подозрение в малоопытности.
ответы ж есть в инете. если чел хочет разобраться.
если же ему важнее встать в позу, «с этим миром что-то не так», ну такое.
человеки тысячителетиями живут с таким ощущением :) в основной массе
но и сам этот вопрос — вообще не о рестфул.
В вакансиях обычно пишут левейший бред.
RESTful API
типа модно и круто. а самое главное никто не может и близко формализовать и пояснить что это такое. нанялся на рестфул апи — сиди себе на рабочем месте и дергай процедуры используя хттп как транспорт. и всем говори что ты типа рестфул
restfulapi.net Насправді є принципи, завжди задавав це питання на співбесідах. Просто JSON based web service дуже не обов’язково RESTful. Є величезна купа софту, де через те, що треба тримати сесію на руках на принципи і Stateless і Cacheble забили орган і тим не меньше усе працює, та буде працювати до тих пір доки не настануть проблеми із горизонтальним масштабуванням, а вони настануть обов’язково і доведеться додавати пам’яті на плодах та платити AWS, Azure чи GCP більше грошей . Та на співбесіді треба щось спитати, щоб зрозуміти що за людина яка в неї кваліфікація (буває і так, що коли тебе співбесідують починать казати, що ті принципи то не те :) я вирішую не вступати в спори в таких випадках, там усе ясно ).
Еще и знание каких-то языков программирования требуют, совсем обнаглели.
ну не знаааю. Переглядав нещодавно вакансії клінінг-менеджерів та спеціалістів з вантажоперенесень — жодних вимог до rest чи api узагалі.
Тож, думаю, варто перефразувати питання. Хай буде щось на кшталт «чи варто погромістам вчити математику?» Бо про уміння лічити, бодай, до сотні я зустрічав.
Oleksii Zazulin
Переглядав нещодавно вакансії клінінг-менеджерів та спеціалістів з вантажоперенесень
друг попросив?)
Спасибо за ответ по теме. Не знал, что клининг менеджеры используют REST для общения со smart клининг шваброй и smart ведром с клининг водой.
Beaver Green
Имхо REST это полный остой, все нормальные чуваки должны использовать RPC.
3 роки тому:
«SOAP и WCF это полный отстой, все нормальные чуваки должны использовать REST»
Блин, пришлось гуглить что такое SOAP и WCF. Спасибо, узнал много нового.
WCF кстате была годная технология. Там можно было регулировать и настраивать как раз уровень транспорта. Но потом набежали всяки джаваскриптеры на нодах со своими игрушечными языками и в конце концов все пригвоздили к http протоколу. Потом опечалились что все стало притормаживать и переизобрели RPC которому 30 лет в обед. Победил бы в этой гонке WCF и никакого RPC не надо было, поскольку как именно ходят данные было частью его конфигурации.
Там можно было регулировать и настраивать как раз уровень транспорта.
Ось! Насправді депелопера не має хвилювати як саме будуть передані данні і відбудеться виклик іншої частини коду. Коли ми викликаємо функцію параметри ідуть у стек і управління передається через адрес у пам’яті. Коли ми викликаємо Windows API функцію — то там вже данні можуть копіюватися до пам’яті іншого процесу і управляння перейде до ядра. Якшо підключимо COM і будемо викликати — десь «під капотом» буже маршалінг, пошук у реєстрі і т.і. Але у багатьох випадках ми пишемо на С# і навіть не замислюємося що там будет «під капотом». Нас навіть не цікавить що код перетвориться на запит до БД, піде по мережі на інший сервер і тільки тоді ми отримаємо результат.
Так чому, коли нам у браузері потрібні данні з сервера ми повинні думати як серіалізовати JSON, як зібрати REST запит, як дочекатися відповіді. А якщо ми хочемо не REST, а веб-сокети? Чи може взагалі щось інше: данні з веб-камери чи аудіо?
Єдина причина чому усе це ще не відпрацьовано і не сховано за «синтаксичним цукром» мови — це звичка вигадувати велосипеди! Обов’язково нові і несумісні ні з чим з попереднього. А потім кричати «старе — відстій, нормальні чуваки повинні писати по-новому».
Победил бы в этой гонке WCF и никакого RPC не надо было
RPC появилось лет на 40 раньше :)
кто кого переизобретал?
RPC это концепция/абстракция, WCF это имлементация, не?
СОАП это отстой. По факту. Вечно с ним куча тупых проблем валидации которые вообще не нужны.
Сначала валидируешь 100500 всякой фигни, потом пишешь «отправить инт обьект». 95% времени ты занят борьбой с протоколом.
Хуже SOAP только H323 из известных мне протоколов.
Все так. Недавно писал «Soap прокси» — потому что два приложения работающих по соап не хотели друг дружку понимать — каждое считало что у другого неправильный соап.
А одно ещё и не хотело законный но редко применяемый способ задания нейспейсов понимать.
Про SOAP — отстой было 15 лет назад, потому что никто не любил мутный и сложный XML с мутными и тяжелыми XML парсерами с полной поддержкой XML схем.
А потім довелося вигадувати схеми для JSON.
Це класичний приклад «нового покоління» в ІТ. Приходить молодь і каже: навіщо ото усе складне та мутне, якщо є найпростіша і найкраща мова — JavaScript! Будемо усе писати на ньому.
Гаразд — нові фреймвокі, 100500 різних NPM пакетів на будь-який смак ... Але потім бізнес починає питати: а ось у мене теперь кастомери у різних таймзонах, а ще є араби, і японці — ви тут мені швиденько зробіть щоб мій сайт усе це підтримував ... Опс — а молоді JS — велосипедисти із глобалізацією не заморочувались. Як і з багато чим, що потрібно для великих проектів. Вони ж люблять коли швидко та просто.
А потім виявляється що усі ті складні мови, як C#, із строгою типізацією, з ООП вигадали не просто так. А тому що як тільки «простого» коду на JavaScript стає забагато — то чомусь він перестає бути простим! Тобто код залишається простим — а от знайти та відстежити логіку стає вже складним.
Це як спаяти компьютер з транзисторів: калькулятор — легко, а ЕОМ — вже декілька шаф на усю кімнату. Що робити — треба мікросхеми! Але ж воні складні — це тобі не транзистор. У цьому парадокс: складне не можна уявити як сукупність простих елементів — бо тоді елементів буде стільки, що людина буде незмозі передивитися їх усі! Можно тільки уявити складне як сукупність менш складних елементів — тобто портібні різні рівні абстракції.
вам, батюшка, талмуди писати, або спічрайтером іти до Вєталя/Вови, а можна і самому починати політичну кар"єру
Нефига. Ты сам когда прошлый раз SOAP то использовал?
Вот как раз с тем, что SOAP отстой — вообще помоему все согласны.
Если есть SOAP вообще боишься трогать API. Один символ поправил и у кого-то обязательно клиент отвалится.
Причем чтоб отправить 20 символов нагрузки используется десятки страниц кода валидаторов и килобайт текста.
Javascript — це не нове покоління, це стара хвороба
Ярослав Характерник
Опис теми схожий на цитати Джейсона Стетхема.
Хочеш, щоб використовували RPC то пиши статті про RPC, які його популяризують й показують переваги.
Oleg Korol
Опис теми схожий на цитати Джейсона Стетхема.
тоді вже ближче до цитат Віталія Кличка
Найкращі коментарі пропустити