Так вы забыли еще написать что и куку шифруются. Только я не понимаю в чем суть вашего высказывания? Через POST можно тело запроса в форматах, чаще всего, в текущих реалиях это json, но я видел системы которые работают через xml. POST удобен для тестирования API из разных инструментов, например в postman, если хочешь поделится запросом то нужно всего лишь отправить json. POST это сложная структура данных, есть запросы авторизации где кроме имени пользователя и пароля передаются дополнительные данные в виде даты-времени, региона, версия приложения и ОС ид. Давай теперь header - это структура ключ-значение. Можно передавать все вышеописанные поля? да можно, но попробуй поделится запросом, curl? "очень удобно". Как заполнить заголовки перед отправкой запроса в хедры? циклом с проверкой, очень удобно. Так а как отправить сложный запрос авторизации? так объект преврати ключ значение, очень удобно. Есть решение чтобы так не делать? да, есть, например digest auth или jwt чтобы решить данную проблему кодируют объект в base64 и отправляют в виде заголовка, так а что там отправляется? да можно декодировать и посмотреть!
А почему так делают амазон или гугл в своих апи? наверное дураки.
Есть REST API, это манифест который описывает как надо проектировать API, а сами API мы разделяем на REST и RESTful, они отличаются тем что второй соответствует всем канонам манифеста.
Очень важно понимать что тело запроса шифруется (при https) и из за этой причины очень часто используется post, например при о правке запроса авторизации.
Еще одним очень важным фактором является то для какого клиента бы делаем API, если это фронт то лучше вернуть 404, если другой бэк то пустой массив, если наши клиент это сторонние системы типа ibm lotus или 1с то лучше реализовать API на get и post миннуя другие методы.
Так что если делаем для масс то лучше придерживаться манифесту и сделать RESTful API в противном случае исходить из клиента, функционал и требований к безопасности.
Сессия это не проблема сервера, именно такие сессии добавляют очень много ограничений и проблем которые надо решать, вот несколько из них: многозадачность, балансировкой запросов, очень сильная зависимость от сетевого соединения, большой жор ресурсов. Из этого следует что проблема имеется у бизнеса с точки зрения сложности разработки и дорого оборудования и проблемы разработчика который должен разбираться и бороться с UI фреймворком вместо того чтобы делать бизнес логику. Кроме этого, Vaadin это на аля Angular, первый это толстый клиент как было подмечено а второй это web фреймворк который после сборки выдает простой html+css+js, который в принципе своей работы ничем не похож на толстый клиент.
Очень много статей на эту тему, я тоже несколько лет назад стоял перед выбором, но к сожалению выбор был не в сторону vaadin. Основная причина это отсутствие возможности масштабирования, то есть если больше одной ноды приложения то надо подумать как синхронизировать сессии, сессия хранит состояние и от этого вытекает много проблем (но есть и плюсы конечно), проблема когда сеть логает и тд
Если коротко - vaadin можно использовать для создания морды которым пользуются мало людей, это может быть какая-то админка или бухгалтерская программа, а вот интернет-магазин не сделаешь.
Чтобы не быть голословным, предлагаю посмотреть доклад на jpoint от Юрий Артамонов — Анатомия и физиология Vaadin Flow
Переделали (микро)сервисную архитектуру в монолитную. На самом деле, на ограниченном домене, очень интересное решение, просто учитывая нынешние тренды на распределенность, морально сложно к этому придти)) но молодцы, круто)
Для построения UI использую библиотеку, в некоторых случаях приходится изменять стили вложенных элементов компоненты (то есть нет возможности непосредственно изменить сам компонент), логика где компонент это одно целое очень хорошая, но ведет к повторению. Тоже думал на тему чтобы использовать миксины, хотя - опять таки, сложно вывести какую то общую часть в стилях не говорю уже об общей компоненте. Видимо с этим только жить ))
У меня такой вопрос - а как быть с повторениями? У меня есть 2 компоненты где специфичная стилизация таблиц, 90% кода совпадает, этого недостаточно чтобы их вывести в глобальной стиль но и непонятно как объединит общую часть стилей, и ещё вопрос - а нужно ли? Ведь это разные компоненты по сути.
Давайте писать на ассемблере! А лучше на машинным коде! Это конечно сарказм, если серьезно то такие "инструменты" как Angular, не упрощают процесс разработки, они его усложняют, но их цель в стандартизации, в общем подходе, в использовании более строгих механизмов контроля типов и тд. По этой же логике зачем мы усложняем наш код разными паттернами проектирования?? Зачем мы следуем определённым принципам? По словам Роберта Мартина это упрощает поддержку проекта, что следовательно, снижает цену поддержки. Ещё обязательно надо помнить - каждая технология хороша там для чего она предназначена! Если проект лучше сделать на чистом js то делайте! А если вам подходит vaadin для рисования ui в java то берите его!
Так вы забыли еще написать что и куку шифруются.
Только я не понимаю в чем суть вашего высказывания?
Через POST можно тело запроса в форматах, чаще всего, в текущих реалиях это json, но я видел системы которые работают через xml.
POST удобен для тестирования API из разных инструментов, например в postman, если хочешь поделится запросом то нужно всего лишь отправить json.
POST это сложная структура данных, есть запросы авторизации где кроме имени пользователя и пароля передаются дополнительные данные в виде даты-времени, региона, версия приложения и ОС ид.
Давай теперь header - это структура ключ-значение.
Можно передавать все вышеописанные поля? да можно, но попробуй поделится запросом, curl? "очень удобно".
Как заполнить заголовки перед отправкой запроса в хедры? циклом с проверкой, очень удобно.
Так а как отправить сложный запрос авторизации? так объект преврати ключ значение, очень удобно.
Есть решение чтобы так не делать? да, есть, например digest auth или jwt чтобы решить данную проблему кодируют объект в base64 и отправляют в виде заголовка, так а что там отправляется? да можно декодировать и посмотреть!
А почему так делают амазон или гугл в своих апи? наверное дураки.
Есть REST API, это манифест который описывает как надо проектировать API, а сами API мы разделяем на REST и RESTful, они отличаются тем что второй соответствует всем канонам манифеста.
Очень важно понимать что тело запроса шифруется (при https) и из за этой причины очень часто используется post, например при о правке запроса авторизации.
Еще одним очень важным фактором является то для какого клиента бы делаем API, если это фронт то лучше вернуть 404, если другой бэк то пустой массив, если наши клиент это сторонние системы типа ibm lotus или 1с то лучше реализовать API на get и post миннуя другие методы.
Так что если делаем для масс то лучше придерживаться манифесту и сделать RESTful API в противном случае исходить из клиента, функционал и требований к безопасности.
Сессия это не проблема сервера, именно такие сессии добавляют очень много ограничений и проблем которые надо решать, вот несколько из них: многозадачность, балансировкой запросов, очень сильная зависимость от сетевого соединения, большой жор ресурсов. Из этого следует что проблема имеется у бизнеса с точки зрения сложности разработки и дорого оборудования и проблемы разработчика который должен разбираться и бороться с UI фреймворком вместо того чтобы делать бизнес логику.
Кроме этого, Vaadin это на аля Angular, первый это толстый клиент как было подмечено а второй это web фреймворк который после сборки выдает простой html+css+js, который в принципе своей работы ничем не похож на толстый клиент.
Очень много статей на эту тему, я тоже несколько лет назад стоял перед выбором, но к сожалению выбор был не в сторону vaadin. Основная причина это отсутствие возможности масштабирования, то есть если больше одной ноды приложения то надо подумать как синхронизировать сессии, сессия хранит состояние и от этого вытекает много проблем (но есть и плюсы конечно), проблема когда сеть логает и тд
Если коротко - vaadin можно использовать для создания морды которым пользуются мало людей, это может быть какая-то админка или бухгалтерская программа, а вот интернет-магазин не сделаешь.
Чтобы не быть голословным, предлагаю посмотреть доклад на jpoint от Юрий Артамонов — Анатомия и физиология Vaadin Flow
да, к сожалению скорость уменьшилась, и запись и чтение были 7к, сейчас запись -2к
Переделали (микро)сервисную архитектуру в монолитную. На самом деле, на ограниченном домене, очень интересное решение, просто учитывая нынешние тренды на распределенность, морально сложно к этому придти)) но молодцы, круто)
Для построения UI использую библиотеку, в некоторых случаях приходится изменять стили вложенных элементов компоненты (то есть нет возможности непосредственно изменить сам компонент), логика где компонент это одно целое очень хорошая, но ведет к повторению. Тоже думал на тему чтобы использовать миксины, хотя - опять таки, сложно вывести какую то общую часть в стилях не говорю уже об общей компоненте. Видимо с этим только жить ))
Спасибо!
Привет, спасибо за статью!
У меня такой вопрос - а как быть с повторениями? У меня есть 2 компоненты где специфичная стилизация таблиц, 90% кода совпадает, этого недостаточно чтобы их вывести в глобальной стиль но и непонятно как объединит общую часть стилей, и ещё вопрос - а нужно ли? Ведь это разные компоненты по сути.
Хотелось бы услышать ваше мнение.
Давайте писать на ассемблере! А лучше на машинным коде! Это конечно сарказм, если серьезно то такие "инструменты" как Angular, не упрощают процесс разработки, они его усложняют, но их цель в стандартизации, в общем подходе, в использовании более строгих механизмов контроля типов и тд. По этой же логике зачем мы усложняем наш код разными паттернами проектирования?? Зачем мы следуем определённым принципам? По словам Роберта Мартина это упрощает поддержку проекта, что следовательно, снижает цену поддержки. Ещё обязательно надо помнить - каждая технология хороша там для чего она предназначена! Если проект лучше сделать на чистом js то делайте! А если вам подходит vaadin для рисования ui в java то берите его!