LINUX.ORG.RU

Общение web сервера и клиента

 ,


0

1

Обычно для обмена информацией между сервером и клиентом люди используют HTTP REST (POST, PUT, GET, DELETE) и возможно еще какую то точку нотификации (HTTP GET или websocket) для отправки данных от сервера клиенту.

Те есть точка добавления/изменения данных (REST), точка получения данных (REST), точка получения данных/нотификаций (HTTP GET или websocket).

Но вот положим отправляешь ты с клиента на сервер запрос, а соединение прервалось и ты не знаешь исполнился твой запрос или нет. Может он не исполнился, а может исполнился но ответ ты не получил это ведь не нормально. Можно потом этот ответ получать скажем в точке нотификации (websocket это HTTP GET не важно).

А можно изначально не ждать ответа, а серверу отправлять только запросы через точку добавления/изменения данных, а ответы асинхронно всегда получать в точке нотификации.

Как вам такой концепт? Точка получения данных - для получения данных на старте. Точка добавления/изменения данных - для отправки команд на сервер без ответа. Точка нотификации для получения ответов на команды и возможно измененных данных, а так же внешних нотификаций. Это могут быть как HTTP запросы, так и websocket запросы, важно что это уже не REST в изначальной концепции.

Возможно это напоминает какие-то существующие фреймфорки, не знаю, обычно использую свои велосипеды)))

Find in Page: точк 1 of 10
прекрати фиксацию на слове «точка», это не нормально.
расскажи, в чём ненормальность возможности не получить от сервера ответ по причине отваливания сети? вроде не 2054 год, сеть всё ещё местами фиговая и это абсолютно нормальное явление since 1946
можно сделать стейтлес идемпотентный сервер с отдельной лентой сообщений [AMQP etc.] и клиентами которые подписываются на топики.
придумать как мачить запрос серверу с сообщением в топике самое сложное из твоего предложения.

system-root ★★★★ ()
Ответ на: комментарий от system-root

в чём ненормальность возможности не получить от сервера ответ по причине отваливания сети?

положим ты отмечаешь какой-то товар, он уже у тебя в корзине, а ты и не знаешь, да куча вариантов.

В принципе не гуд что есть точка или API, метод если вам угодно получения данных и другой метод получения данных/нотификаций, вроде как лишняя сущность да еще и с возможностью не получить ответ

quester ()
Ответ на: комментарий от quester

вроде как лишняя сущность да еще и с возможностью не получить ответ

сущностей IRL чуть менее чем дофига https://i.imgur.com/Zo9SPc4.png и «с возможностью не получить ответ».
так что, этот довод отметаем сразу.
вариант «клиент будет получать данные быстрее» тоже отпадает, клиент должен ждать ответа от некого источника прежде чем послать второй запрос, в случае если у них зависимости.
вариант «клиент будет получать данные стабильнее» отпадает просто потому, что данные могут устареть пока у него не было сети. получить 100500 ответов через полтора часа интересно только программам\ботам\скриптам, а не людям.
в итоге: это сложнее, чем получить ответ сразу, послав запрос, а профита с первого взгляда и не усмотреть.

system-root ★★★★ ()
Ответ на: комментарий от quester

положим ты отмечаешь какой-то товар, он уже у тебя в корзине, а ты и не знаешь, да куча вариантов.

так обрабатывай разрыв соединения и обновляй корзину при подключении

Frost ★★★ ()

Поздравляю, ты открыл Command Query Segregation в одной из форм.
Для рядовых оперденей почти не нужно, а все кто хотел уже давно строит event driven архитектуру.
Но особо это не решает вопрос с правильным повторением запросов, один фиг система должна обладать идемпотентностью.

Deleted ()