Comments 10
А что будет, если посмотреть на эти проблемы с точки зрения обыкновенных настольных приложений? Без всяких, там, http. Если бы внутри ОС был бы модуль управления пользовательскими данными, то нужно было бы просто указывать внешний источник данных и больше ничего.
При http-request в ответе возвращается верстка. Т.е. мы зависим от форматирования, от тегов, от стилей. Соответственно, если поставщик данных поменяет верстку, все поломается.
При использовании HTTP всегда в ответе передаётся веб-страница? Мой вам ответ на это:
267 Сомнительно, но окей
И еще: HTTP и push вы считаете отдельными типами интеграции. Они не укладываются в паттерн RPC/API?
Да, это разные типы интеграций.
И нет, нельзя сказать, что HTTP-запросы и push-каналы укладываются в один тип интеграции, даже если они могут быть реализованы в рамках одного паттерна (gRPC/API). Просто потому, что представляют собой две принципиально разные модели взаимодействия:
HTTP-запросы - синхронная модель "запрос-ответ".
Push-каналы - асинхронная модель событийной передачи данных.
И несмотря на то, что и gRPC, и API могут поддерживать как синхронные, так и асинхронные методы взаимодействия, сами по себе HTTP-запросы и push-каналы остаются разными типами интеграций.
2698 из 16384
Я все же еще побрюзжу
паттерна (gRPC/API)
qRPC - конкретный фреймворк и протокол. А паттерн интеграции - RPC
Паттернов интеграции, видимо, всего 4: файлообмен; shared db, RPC, message.
А HTTP(s) - это конкретный протокол (на котором построено множество разных RPC). Использование HTTP не ограничивается передачей веб-странички браузеру и вообще не ограничивается "передачей данных в сети Интернет". Компоненты одной системы вполне себе могут быть интегрированы по какому-нибудь RPC и взаимодействовать по HTTP внутри своего интранета.
Push-каналы - асинхронная модель событийной передачи данных
паттерн Message?
PATCH запрос забыли)
Не забыла, специально не писала) Статья предназначена для новичков, которые возможно не слышали про более редко встречающиеся запросы, такие как patch, options, head. И т.к запросы - не центральная тема статьи, и они здесь упоминаются лишь мельком, не вижу смысла пугать людей тем, с чем они, вероятно, не сталкивались прежде
В статье, несмотря на объем и обширность обозрения технологий, все намешано в кучу без всякой системы. Данная статья показывает, что роль аналитика в кризисе
REST HTTP эндпоинт всегда возвращает вёрстку? А какой CSS лучше для этой вёрстки тогда использовать? И JavaScript поддерживается?
Не советую новичку это читать. Какая-то дикая смесь всего со всем, потом потратите гораздо больше времени на исправление своих знаний.
Прямо с первой же картинки. Попробуйте определить, кто на ком там стоял - компоненты системы чудесным образом взаимодействуют то ли с архитектурным стилем, то ли с API в вакууме (сервер-то отдельно нарисован).
Схемы "неоднородных", прости господи, фронта и бэка просто чудесны, но тут уж сами, мне дальше лень
Общие принципы интеграций систем. SA для самых маленьких