[2020 06 17] REST HTTP? (need fix)
Andrey Alekseev 7:39 PM Помогите, пожалуйста, разобраться с понятием REST. После чтения статьи на вики, я сделал вывод, что по сути HTTP - это одна из реализаций концепции REST. Правильный ли вывод? Почитал диссертацию Roy Fielding от 2000 года. Описываемая проблема: в девяностых годах стало ясно, что, в частности, текущие реализации http не соответствуют резко увеличивающейся/усложняющейся сети интернет. Из-за чего был поставлен вопрос: как изменить текущую реализацию, сделав ее масштабируемой, надежной и тд и тп. не разрушив при этом старую? Реализация первой версии протокола HTTP не основывалась на каких-то обоснованиях. Не было описания архитектуры. Рой Филдинг решил исправить это и начал описывать новую архитектуру через ограничения, формируя таким образом желаемую архитектуру. Набор этих ограничений назван REST. И эти идеи легли в основу изменения HTTP, чтобы последний поддерживал архитектуру REST. Как итог моих исследований вопроса. HTTP не является однозначной реализацией REST, но поддерживает большинство идей REST. Текущий HTTP - это попытка объединить ранний HTTP с идеями REST. Что-то получилось, что-то нет (из-за требования обратной совместимости с ранним HTTP). В частности, наличие и использование в протоколе HTTP файлов cookies противоречит архитектуре REST. В целом, описывая кратко взаимоотношение между REST и HTTP, можно ответить предложением, которое я нашел на stackoverflow: REST means using HTTP the way it’s meant to be.
Kirill Samsonov:roll_safe: 7:57 PM Как http может реализовать REST, когда rest это набор принципов, а http это конкретный протокол уровня представления модели OSI? http не поддерживает REST, более того, он ничего не знает о том, как его будет использовать вышележащее приложение.
Kirill Samsonov:roll_safe: 7:58 PM Куки вообще никакого отношения не имеют к http
Andrey Alekseev 8:09 PM Собственно, на основе принципов REST реализуется протокол HTTP, что тут непонятного? REST - это не вышележащее приложение. Это набор принципов, в том числе на основе которых реализован современный HTTP. Используя HTTP, вы используете REST.
nikita naumenko:random2_expert: 8:09 PM нет не может то что находится ниже уровнем, реализовываться тем что лежит выше (edited)
Andrey Alekseev 8:10 PM нет никаких разных уровней)
nikita naumenko:random2_expert: 8:10 PM давно osi отменили? с утра еще вроде как актуальна была
Andrey Alekseev 8:11 PM нет никаких разных уровней в рамках этого вопроса вы используете REST идеи через имплементацию в виде HTTP
nikita naumenko:random2_expert: 8:12 PM я могу не использовать рест и я все еще буду использовать http
Andrey Alekseev 8:12 PM да, например, когда используете cookies
Andrey Alekseev 8:12 PM потому как реализация неполная ребят, ну почитайте сырцы, я два часа текст читал. Почитаете, придете с аргументацией. Пожалуйста. https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
Andrey Alekseev 8:19 PM Возможно, я ошибаюсь. Если ошибаюсь, давайте вместе разберемся. Но не надо сразу кидаться помидорами. В любом случае это интересное чтиво: как создавался REST, почему в его архитектуре именно такие правила и почему HTTP протокол сейчас такой, какой есть.
Sergey B:elephant: 8:37 PM А "SOAP идеи" я через что использую? :pepe_think: (edited) Andrey Alekseev вы используете REST идеи через имплементацию в виде HTTP
Andrey Alekseev 8:42 PM Соап это не идеи, это протокол. Который используется поверх протокола http. REST - это архитектурный подход, который частично реализуется через http.
kirill.mokevnin 8:42 PM у нас на хекслете есть урок где это рассказывается
rest правильно понимается через историческую призму
изначально http мало кем использовался как протокол прикладного уровня прямо по назначению, в основном его воспринимали как транспорт для rpc
в том числе soap
пока один не глупый мужчина не заметил что http это не только транспорт, у него есть определенная семантика вполне прикладная
а еще современному интернету нужна масштабируемость
но по факту подавляющее большинство разработчиков думает что rest это и есть http api
максимум знают про ограничения некоторые и типа урлы надо делать правильно
в лучшем случае знают про методы
а про генеральную идею о создании масштабируемых и совместимых приложений не знают
но это довольно типичная история, когда средство подменяет цель
например одна из ключевых идей rest это self descriptive message и отсутствие стейта на сервере (без этого невозможно масштабироваться нормально, не будет вам балансера с кучей ап серверов)
и я не раз наблюдал картину когда человек топит за рест, при этом у него на сервере в памяти есть стейт
кстати понятие сессии противоречит ресту
в итоге все с чем мы имеем дело это rest-like
для достижения тех целей что я описал выше, но без фанатизма
потому что слепое следование приведет в обратную сторону, все станет сложнее и хуже
в общем типичный инженерный трейдоф
если вы до сюда дочитали, рельсы сила, фронтенд могила
4 replies Last reply 8 days agoView thread
Dmitriy 9:19 PM @melodyn хорошо разложил, все понятно
Dmitriy Bataev 9:22 PM Да и классы в js вообще фикция.
Pavel Novoselov 9:23 PM Ну не совсем фикция, но с точки зрения Java программиста, штука странная.
aelaa 9:24 PM с точки зрения Java-программиста любые нормальные классы странная штука 9:24 непонятно чем оно тогда должно быть
Pavel Novoselov 9:25 PM Ну с моей точки зрения, с классами в Java все ок, а вот то что их используют неправильно, так это претензии к тем, кто так пишет
Anatoly 9:30 PM replied to a thread: в среднем у php разработчиков общее понимание ооп выше чем у js Это потому, что на Хекслете ООП курсы в PHP завершены, а в JS всё никак) :trollparrot: 2 :kekeke: 2 :oh_all: 2
nikita naumenko:random2_expert: 9:31 PM специальный заговор чтобы фронтендеры не освоили ооп
Ruslan S 9:31 PM Зато денег больше платят :batya: 3
Quramolt 9:58 PM https://www.notion.so/71b8e48c66d94332977ba98dc981d246?v=b50b739025484fee8cbc8628664895a1&p=9433a40ffeaa41cc828127e94072411b вот оно как Hexlet on NotionHexlet on Notion Основы Mongodb A new tool for teams & individuals that blends everyday work apps into one. :ktotam:
kirill.mokevnin 10:07 PM ага, это такие штуки о которых я мечатл еще до хекслета 10:07 свои языки, лупы, базы, веб сервера 10:07 мы все это будем делать 10:07 свои фреймворки
Quramolt 10:08 PM да там всё интересно звучит, даже и простое. типа деплоя или профилирования (edited)
kirill.mokevnin 10:08 PM velosiped.hexlet.io :+1: 1 :roll_safe: 3 :trollface: 1
1 reply 8 days agoView thread
kirill.mokevnin 10:09 PM сами мы это все никогда не сделаем, а вот в таком формате 10:09 нахерачим столько что мама не горюй! 10:09 если кто готов, можно по битриксу фигануть трек
Andrey Konstantinov 10:09 PM А в курсера курсы проходят ревью на качество администрацией сайта? (edited)
kirill.mokevnin 10:10 PM у нас есть мега преимущество (и одновременно недостаток) 10:10 так как курсы текстовые 10:10 то очень легко трекать насколько оно хорошо
Andrey Konstantinov 10:11 PM почему недостаток?
Evgeniy 10:11 PM Кирилл, ты писал: например одна из ключевых идей rest это self descriptive message и отсутствие стейта на сервере (без этого невозможно масштабироваться нормально, не будет вам балансера с кучей ап серверов).
В тоже время 4 проект фронт есть и стейт на сервере и REST. Значит так делать нельзя?
kirill.mokevnin 10:15 PM я выше подчеркивал что нельзя быть rest на 100 процентов, потому что это начинает противоречить здравому смыслу
само наличие вебсокетов уже противоречит идеям реста, потому что оно говорит о том что у нас постоянный коннект
и отсюда не следует что это плохо
отсюда следует что нам нужно состояние
а значит мы даже не пытаемся притягивать сюда рест
потому что он для этой ситуации не нужен/не подходит
проблема есть только тогда, когда программист делает апи которое по своему смыслу может быть rest совместимым, но он по ошибке (по не знанию) делает его не правильно
типа добавляя стейт на сервер (edited)
только тогда это косяк и уволен (edited)
любые постоянные коннекты (любой софт риалтайм, чаты, игры) это сразу очень сложно, потому что есть стейт на сервере
это само по себе важно понимать, потому что тогда программист сможет оценивать реальную сложность, понимать проблемы с которыми он столкнется (обработка ошибок, производительность, масштабирование)
Evgeniy 10:22 PM А стейт и база данных в этом понимании - разные вещи?
kirill.mokevnin 10:24 PM база данных то где он хранится, но в софт риалтаймовых приложениях стейт не кладут сразу в базу
как при обычном взаимодействии
в кодбатле например стейт прямо в памяти прилоежния
и он периодически сбрасывается в базу
это совсем другой процесс, там действуют другие законы
когда вы играете в игры по сети
то все что там происходит хранится в памяти на сервере
например это означает что нельзя прсото так взять и перекинуть вас на другой сервер 10:26 а если умрет сервер то умрут и все данные (если не успели засинкаться с базой)
kirill.mokevnin 10:26 PM а еще тут сразу всплывают всякие редисы и другие специализированные базы под быстрые данные и разного рода вычисления
Evgeniy 10:27 PM Спасибо за ответ!
Anton 10:30 PM любые постоянные коннекты (любой софт риалтайм, чаты, игры) это сразу очень сложно, потому что есть стейт на сервере хм, а можно реализовать постоянный коннект без стейта вообще? Например просто отсылать пакеты с данными с сервера в "эфир" не требуя подтверждения их доставки, а на клиенте просто ловить пакет и разбирать его (edited)
Quramolt 10:31 PM а видеосвязь не так работает?
kirill.mokevnin 10:32 PM дело ведь не в подтверждении
а в том что текущее состояние чата например должно быть на сервере
текущее состояние игры тоже
в софт риалтайме у вас всегда есть состояние происходящего
и оно быстро (очень быстро) меняется 10:33 и не нужно в базе как правило (по крайней мере не вся его часть) 10:33 вообще само понятие “постоянный коннект” подразумевает стейт 10:33 сам коннект хранится на сервере (edited)
Anton 10:33 PM текущее состояние может же быть в теории не важно?
kirill.mokevnin 10:34 PM состояние это сама жизнь я бы сказал
мы ради этого что0-то и делаем
как в игре может быть не важна игра? 10:34 как в чате может быть не важен чат? 10:34 иначе зачем нам постоянный коннект?
Quramolt 10:34 PM видимо, имеется ввиду прямой коннект между клиентами. например, без сохранения истории
kirill.mokevnin 10:35 PM ну там еще сложнее, вы знаете что такое мастера лидер элекшен и вот это все? 10:35 это ведь огромная и сложная область распределенных систем 10:35 и она вся насквозь про состояние 10:35 про eventual consitency
Anton 10:35 PM не я к тому, что получать информацию и обрабатывать как есть. То есть если я кусочками получаю картинку с сервера и один из кусков не дошел, мне например не критично я просто отображаю, что мне поступает и не знаю о стейте ничего
kirill.mokevnin 10:36 PM но стейт то на сервере 10:36 он же знает какую картинку тебе слать 10:36 он знает кто в игре 10:36 знает что щас происходит и контролирует это 10:36 собственно это и есть сама игра
Anton 10:36 PM ну бродкаст например считывает с носителя видео, рассылает пакеты всем подряд, считал байт данных - закинул в сеть (edited)
kirill.mokevnin 10:37 PM да но рассылает то он что? 10:37 стейт 10:37 данные 10:38 если нет стейта, то и рассылать нечего
Anton 10:40 PM :slightly_smiling_face: я видимо не понимаю. Представим, что у нас есть бесконечная лента на ней 0 и 1 хаотично раскиданы, читающая головка бежит по этой ленте, как только нашла символ передала его в эфир бродкастом на всех и побежала дальше. Что в данном случае стейт?
kirill.mokevnin 10:40 PM твоя лента это стейт
kirill.mokevnin 10:40 PM она находится в конкретном месте и отдает данные конкретным местом
1 reply 8 days agoView thread
Anton 10:40 PM хм, а можно реализовать постоянный коннект без стейта вообще? Например просто отсылать пакеты с данными с сервера в "эфир" не требуя подтверждения их доставки, а на клиенте просто ловить пакет и разбирать его (edited) TCP вроде не просто так ждет подтверждения получения
kirill.mokevnin 10:40 PM ты подключаешься на другую машину и там этого нет 10:40 у тебя оно не в вакууме 10:40 когда у тебя какая томашина раздает видос
Anton 10:40 PM пакет всегда может затеряться
kirill.mokevnin 10:40 PM то этот видос есть на этой машине
Anton 10:41 PM то есть в данном случае то, что на ленте находится получается
kirill.mokevnin 10:41 PM пока ты вообще не о том говооришь 10:41 стейт это данные 10:41 то что мы хотим получить 10:41 доставка тут вообще не причем 10:41 разница в том что наличе постоянного стейта все усложняет 10:41 давай тупой пример 10:41 вот например мы делаем веб сервис и складываем картинки прямо на сервер 10:42 проблему понимаешь?
Anton 10:42 PM мы два разных Антона 😄
kirill.mokevnin 10:42 PM появился стейт на сервере 10:42 а елки 10:42 :smile:
Anton 10:42 PM :smile:
kirill.mokevnin 10:42 PM :batya-smokes: 10:42 запутали братья близнецы
Anton 10:42 PM я просто про идею сразу доставлять к клиенту не дожидаясь подтверждения 10:42 вроде это нерально... 10:42 массово не реально 10:42 в каких-то лабораторных условиях может и можно
kirill.mokevnin 10:43 PM читай про семантику доставки сообщений в распределенных системах 10:43 а дальше http/3
Anton 10:43 PM есть просто вот такая тема, вот и спросил 🙂 10:43 https://ieeexplore.ieee.org/document/1203451 ieeexplore.ieee.orgieeexplore.ieee.org SPEED: a stateless protocol for real-time communication in sensor networks - IEEE Conference Publication IEEE Xplore, delivering full text access to the world's highest quality technical literature in engineering and technology. | IEEE Xplore
kirill.mokevnin 10:44 PM протокол то может быть стейтлес, но данные то они не стейтлес 10:44 это и есть стейт 10:44 вот например мы делаем веб сервис и складываем картинки прямо на сервер 10:44 все может быть тысячу раз стейтлес 10:44 но если картинки лежат на конкретнмо сервере 10:44 то это стейт 10:44 на конкретном сервере 10:44 и масштабирование тут ноль 10:45 потому что нельзя просто взять и начать балансировку делать
Anton 10:45 PM получается даже если датчик температуры например ничего в себе не хранит то данные которые он показывает это и есть его стейт. Что логично, как бы состояние датчика 🙂
kirill.mokevnin 10:46 PM ну конечно, если ты подключишься к другому датчику 10:46 то у тебя не будет данных первого датчика 10:46 в этом и проявляется состояние 10:46 что оно где то 10:46 в конкретном месте 10:46 куда тебе надо идти за ними 10:47 поэтому когда речь идет про масштабирование в веб проектах 10:47 то основная проблема это стейт 10:47 если в памяти конкретного процесса с приложением есть стейт 10:47 то все, никакого масштабирования 10:47 никакой балансировки нагрузки 10:48 поэтому app сервера делают стейтлесс 10:48 данные хранят в базе (если это возможно) 10:48 и дальше мы поверх базы ставим 100 серверов 10:48 и делаем раундробин балансировку 10:48 все вот тебе масштабирование 10:48 но только при условии что ни один из этих серверов не хранит у себя ничего 10:48 типа картинок 10:48 или данных в памяти
Anton 10:49 PM @kirill.mokevnin про семантику это вот? https://habr.com/ru/company/badoo/blog/333046/ ХабрХабр Семантика exactly-once в Apache Kafka Всем привет! Меня зовут Юрий Лилеков, я работаю в Server Team Badoo. На днях мне попалась довольно интересная статья о новой семантике exactly-once в Apache Kaf... (33 kB) https://habr.com/share/publication/333046/dfd21a7ad4df31d500f40bb59c42d715/?v=1
kirill.mokevnin 10:49 PM вот, прямо прекрасно 10:49 оно самое 10:50 поменяйте аватарки! 10:50 пыщпыщ
Anton 10:50 PM так я тут, как понимаю, про программную доставку я же подразумевал железо на уровне проводов и каналов беспроводной связи можно ли не проверять что доставлено?
kirill.mokevnin 10:51 PM железо и не проверяет, проверяет софт 10:51 причем на многих уровнях 10:51 хотя я вру, железная коррекция тоже сть
Anton 10:51 PM начиная с TCP?
kirill.mokevnin 10:51 PM на самом низком уровне 10:51 не, там ниже еще еесть 10:51 @naphaso тут лучше скажет
Anton 10:52 PM ну в принципе сеть, на данном уровне технологии, массово идеальной быть не может муфты, длинные участки, последняя миля... везде есть потери же 10:52 да банально, свет дома/в офисе рубанули 10:52 как без подтверждения?
Anton 10:53 PM Если в памяти процесса А на сервере B есть стейт, то если мы клонируем сервер B вместе с процессом А, у нас не при каких условиях не получится горизонтально масштабирироваться
Anton 10:53 PM пошел менять аву 🙂
kirill.mokevnin 10:54 PM я все заранее продумал https://www.youtube.com/watch?v=WPCz_U7D8PI YouTubeYouTube | Хекслет Вебинар: Stateful vs. Stateless [Хекслет]
10:54 могу на любой разговор видосами отвечать
Anton 10:56 PM image.png image.png
7
10:56 :slightly_smiling_face:
Dmitriy Bataev 10:57 PM Ну так, попроси сделать скринкаст)))
Anton 10:58 PM да это я так, шучу 🙂
Dmitriy Bataev 10:59 PM Ничего, я думаю скоро чатики сделают автоматом скринкасты таких аудио дорожек.
Anton 10:59 PM @kirill.mokevnin А так на счет той диссертации по REST - не читать её?
kirill.mokevnin 10:59 PM я немного просматривал 10:59 лишним не будет думаю 11:00 но что точно стоит читать это http доку 11:00 официальную!
kirill.mokevnin 11:00 PM вопрос на засыпку, можно ли посылать body в get запросе? :kekeke: 1 :oh_all: 3
1 reply 8 days agoView thread
Anton 11:00 PM нет?
kirill.mokevnin 11:01 PM не скажу :kolobok_gopnik: 1
Anton 11:01 PM было бы удобно, кстати, если на хекслете были собраны бы ссылки на документации - типа "проверенные источники"...
Dmitriy Bataev 11:02 PM Просто статьи на хабре не читай и всё)) :batya: 1
kirill.mokevnin 11:03 PM https://tools.ietf.org/html/rfc7231 11:03 https://tools.ietf.org/html/rfc2616 11:03 оно смотрится страшновато, но читается легко и удивительно неплохо написано
Quramolt 11:03 PM я опять забыл :okay: типа можно, но ничего не гарантируется?
kirill.mokevnin 11:03 PM стандарт не запрещает, но использовать такое тело нельзя 11:04 короче странное у него состояние 11:04 https://tools.ietf.org/html/rfc2616#section-9.1.1 11:04 например вот 11:04 прекрасно про идемпотентность 11:04 и это лучшее что можно прочитать по этой теме 11:04 потому что тут правда матка как она есть 11:04 все остальное это кривые интерпретации
Anton 11:20 PM image.png image.png
1 reply 8 days agoView thread
naphaso:golang: 11:21 PM рфц вообще можно рассматривать как примеры идеальной написанной документации по протоколам. и всем стоит их читать 11:24 работа и ошибками, ретраями, присутствует на всех сетевых уровнях, но фичи и гарантии различаются
naphaso:golang: 11:30 PM уровень 802.3 (ethernet) или 802.11 (wifi) - есть чексуммы во фреймах, есть обнаружение конфликтов, когда стороны одновременно шлют данные и они в проводе или радиосреде смешиваются, слабая проверка на поврежденные фреймы. гарантий никаких, все эти проверки только для того чтобы снизить процент ошибок которые доходят до верхних уровней и улучшить производительность. в 802.11 особенно хитрые алгоритмы, потому что радиосреда общая на всех во все стороны. фреймы переотправляются с рандомными задержками если обнаружена фигня в кэрриере уровень IP - есть чексумма заголовков IP, сами данные не проверяются, проверка заголовков нужна чтобы уменьшить вероятность неправильной маршрутизации пакетов, если примеру адрес получателя-отправителя повредился в пакете (edited) 11:32 3. на уровне TCP - тут есть хитрая чексумма всего пакета плюс "виртуального заголовка IP". т.е. при вычислении чексуммы туда присобачиваются ещё некоторые поля с IP уровня 11:33 все эти чексуммы и обнаружение ошибок - это слабые чексуммы, CRC32/CRC16. они не могут гарантировать, что пакет не поврежден, они могут только снизить вероятность того что он поврежден и это не было обнаружено 11:34 если битые данные умудрились дойти ниже TCP уровня - это скорее всего приведет к тому что соединение будет жестко порвано с ошибкой, но вероятность такого один на много миллиардов 11:35 но тем не менее это налагает на разработчиков прикладных протоколов обязанность более строгой проверки целостности данных 11:36 к том же TLS используется HMAC или AEAD-шифрование для строгой проверки целостности, который снижает вероятность незаметного повреждения данных до нуля 11:37 она гарантированно будет обнаружена и соединение будет порвано 11:41 для прикладных разработчиков (edited) 11:41 тьфу 11:42 для прикладных разработчиков это означает: если вы используете HTTP без шифрования - вы рискуете тем что получите битые данные и это нигде не будет обнаружено если вы используете HTTPS - соединение в любой момент может быть порвано на середине, неважно какая у вас надежная сеть, вероятность остается. но хотябы можно быть уверенным что данные не побиты по пути