Ну к'мон, ребят, а то ж вы сами не видите что это натягивание совы на глобус.
Так, давайте ещё раз. Идея RESTful-а в чём? В том, чтобы иметь на каждую сущность набор HTTP-методов для работы с ним. Они не имеют состояния (в смысле что не держат сессию пользователя - так-то HTTP - это стейтлесс протокол), работают по возможности быстро и, как результат, хорошо линейно скейлятся. Прекрасное начинание, но чуваки, придумавшие REST явно хотели больше чем лавров Капитана Очевидность.
И дальше началась специальная олимпиада: REST определяет конвеншоны касательно вида URI и использования HTTP verb-ов. Не следовать им нельзя, потому что тогда "у вас не REST". Только эти конвеншоны неудобные, противоречивые и негибкие. Щас на примерах покажу.
Вот есть у нас товар (любимый пример в онлайн-туториалах). Делаю эндпоинт /api/good/XXX, вешаю на него verb-ы. Всё хорошо, даже коды HTTP правильные возвращаю.
А потом у товара появляется свойство "компания-производитель". И как дальше? Для компании-производителя мне заводить отдельный REST-эндпоинт, а в товаре возвращать Id компании? То есть мне чтобы достать товар с информацией о производителе - надо 2 запроса подряд делать? И что дальше - на каждую связь один-ко-многим - по одному запросу на сервер? На каждую сущность? Мне вам посчитать, или сами на калькуляторе перемножите? Я не хочу, чтобы клиент 2 часа подтягивал данные и DDoS-ил сервер!
Поехали дальше: А если у меня сложный и многокомпонентный запрос на поиск товаров? Типа "хочу всех квадратных плюшевых мишек дешевле пяти, но дороже двух тысяч, из букв названия которых можно сложить слово ЖОПА, с кожаной животом и динамиком, поющим Диму Билана при нажатии с возможность доставки по Усть-Хтоньску в ночное время но не позднее двух часов". 2048 символов квери-строки хватит всем, да? А иначе придётся складывать в JSON параметры поиска и посылать POST-ом, что в REST делать нельзя, потому что у нас же семаааантика.
А вот на сайте мы, скажем, отображаем список пользователей с именем, возрастом, аватаркой, краткой биографией, датой рождения и емейлом. А в мобильном приложении - просто аватаркой и именем. И что - и мобильное приложение и сайт должны при каждом запросе стягивать список пользователей со всеми доступными полями, да? А если там 150 полей, плюс вложенные? Канал-то сетевой не резиновый. Чтобы решить эту проблему по-умному - нужна система работы с проекциями. А тут или опять посылай запросы POST-ом с указанием нужной проекции (что уже не REST), или лепи 100500 эндпоинтов, возвращающих одни и те же данные в разных проекциях на разные случаи жизни.
Ну и всё равно останутся ещё и RPC-онли эндпоинты, которым ты будешь говорить что-то в духе "удали все товары старше 30 дней у вот этих компаний", а они тебе будут отвечать 200 OK и количество удалённых товаров в JSON-е возвращать. REST-овики вообще говорят что это называется "RPC over HTTP" и типа этого вообще не должно быть. Прямо как в том анекдоте: "Доктор, слова нет а жопа есть", ага. Нет, а как иначе? Сначала запрашивать все товары старше 30 дней, получать список из 100500 штук и для каждого делать DELETE /api/good/XXX? Ну если так, то догадываюсь зачем нам столько скалабилити.
И это не какие-то хитрые примеры с потолка. Вполне штатные ведь юскейсы.
А внимательный читатель уже давно заметил, что ни на состояние, ни на скалабилити эти конвеншоны никак не влияют. Это просто названия. Короче, опять решаем в какой цвет покрасить велосипедный сарай.
Остаётся дежурно напомнить, что даже такие мастодонты как CORBA, SOAP с WSDL, gRPC, WCF в .NET никого не спасли и всё ещё весьма проблематичны (или мертвы). А тут у нас налицо непродуманная, слабая, чудовищно медленная, но пышущая радикальным юношеским максимализмом концепция. Сделает ли она чью-либо жизнь лучше? Не думаю.
Такие дела.
P.S: Ах, да. Есть же GraphQL. Язык/протокол, натягивающийся на другие языки и протоколы, чтобы выставить базу данных во внешний мир и писать запросы на JSON вместо специализированного языка для запросов. Кринж на уровне идеи, извините.
Ну к'мон, ребят, а то ж вы сами не видите что это натягивание совы на глобус.
Так, давайте ещё раз. Идея RESTful-а в чём? В том, чтобы иметь на каждую сущность набор HTTP-методов для работы с ним. Они не имеют состояния (в смысле что не держат сессию пользователя - так-то HTTP - это стейтлесс протокол), работают по возможности быстро и, как результат, хорошо линейно скейлятся. Прекрасное начинание, но чуваки, придумавшие REST явно хотели больше чем лавров Капитана Очевидность.
И дальше началась специальная олимпиада: REST определяет конвеншоны касательно вида URI и использования HTTP verb-ов. Не следовать им нельзя, потому что тогда "у вас не REST". Только эти конвеншоны неудобные, противоречивые и негибкие. Щас на примерах покажу.
Вот есть у нас товар (любимый пример в онлайн-туториалах). Делаю эндпоинт /api/good/XXX, вешаю на него verb-ы. Всё хорошо, даже коды HTTP правильные возвращаю.
А потом у товара появляется свойство "компания-производитель". И как дальше? Для компании-производителя мне заводить отдельный REST-эндпоинт, а в товаре возвращать Id компании? То есть мне чтобы достать товар с информацией о производителе - надо 2 запроса подряд делать? И что дальше - на каждую связь один-ко-многим - по одному запросу на сервер? На каждую сущность? Мне вам посчитать, или сами на калькуляторе перемножите? Я не хочу, чтобы клиент 2 часа подтягивал данные и DDoS-ил сервер!
Поехали дальше: А если у меня сложный и многокомпонентный запрос на поиск товаров? Типа "хочу всех квадратных плюшевых мишек дешевле пяти, но дороже двух тысяч, из букв названия которых можно сложить слово ЖОПА, с кожаной животом и динамиком, поющим Диму Билана при нажатии с возможность доставки по Усть-Хтоньску в ночное время но не позднее двух часов". 2048 символов квери-строки хватит всем, да? А иначе придётся складывать в JSON параметры поиска и посылать POST-ом, что в REST делать нельзя, потому что у нас же семаааантика.
А вот на сайте мы, скажем, отображаем список пользователей с именем, возрастом, аватаркой, краткой биографией, датой рождения и емейлом. А в мобильном приложении - просто аватаркой и именем. И что - и мобильное приложение и сайт должны при каждом запросе стягивать список пользователей со всеми доступными полями, да? А если там 150 полей, плюс вложенные? Канал-то сетевой не резиновый. Чтобы решить эту проблему по-умному - нужна система работы с проекциями. А тут или опять посылай запросы POST-ом с указанием нужной проекции (что уже не REST), или лепи 100500 эндпоинтов, возвращающих одни и те же данные в разных проекциях на разные случаи жизни.
Ну и всё равно останутся ещё и RPC-онли эндпоинты, которым ты будешь говорить что-то в духе "удали все товары старше 30 дней у вот этих компаний", а они тебе будут отвечать 200 OK и количество удалённых товаров в JSON-е возвращать. REST-овики вообще говорят что это называется "RPC over HTTP" и типа этого вообще не должно быть. Прямо как в том анекдоте: "Доктор, слова нет а жопа есть", ага. Нет, а как иначе? Сначала запрашивать все товары старше 30 дней, получать список из 100500 штук и для каждого делать DELETE /api/good/XXX? Ну если так, то догадываюсь зачем нам столько скалабилити.
И это не какие-то хитрые примеры с потолка. Вполне штатные ведь юскейсы.
А внимательный читатель уже давно заметил, что ни на состояние, ни на скалабилити эти конвеншоны никак не влияют. Это просто названия. Короче, опять решаем в какой цвет покрасить велосипедный сарай.
Остаётся дежурно напомнить, что даже такие мастодонты как CORBA, SOAP с WSDL, gRPC, WCF в .NET никого не спасли и всё ещё весьма проблематичны (или мертвы). А тут у нас налицо непродуманная, слабая, чудовищно медленная, но пышущая радикальным юношеским максимализмом концепция. Сделает ли она чью-либо жизнь лучше? Не думаю.
Такие дела.
P.S: Ах, да. Есть же GraphQL. Язык/протокол, натягивающийся на другие языки и протоколы, чтобы выставить базу данных во внешний мир и писать запросы на JSON вместо специализированного языка для запросов. Кринж на уровне идеи, извините.
On June 7, Perekopsky met with Brazilian President Jair Bolsonaro, an avid user of the platform. According to the firm's VP, the main subject of the meeting was "freedom of expression." So far, more than a dozen different members have contributed to the group, posting voice notes of themselves screaming, yelling, groaning, and wailing in various pitches and rhythms. As the broader market downturn continues, yelling online has become the crypto trader’s latest coping mechanism after the rise of Goblintown Ethereum NFTs at the end of May and beginning of June, where holders made incoherent groaning sounds and role-played as urine-loving goblin creatures in late-night Twitter Spaces. Commenting about the court's concerns about the spread of false information related to the elections, Minister Fachin noted Brazil is "facing circumstances that could put Brazil's democracy at risk." During the meeting, the information technology secretary at the TSE, Julio Valente, put forward a list of requests the court believes will disinformation. Just as the Bitcoin turmoil continues, crypto traders have taken to Telegram to voice their feelings. Crypto investors can reduce their anxiety about losses by joining the “Bear Market Screaming Therapy Group” on Telegram.
from us
