как ничего не удаляется навсегда.
Если нет такого кода, который покрывает состояние (такое бывает?), то выдается ближайший по спецификации и в response передается уточнение.
Вебсокетам не нужен rest, он передает не состоение, а message с изменениями от сервера по открытым каналам, это другой тип запросов, и другой способ его обработать.
graphql это другой архитектурный стиль, где сервер становится базой данных.
Нам нужно было сделать api, и было оговорено, что для клиента удобен restfull.
Rest, restfull это все баззворды, есть только транспорты и тот факт стоит ли завязываться на особенности протокола конкретного транспорта или нет. Например что проще - передать объект {action: "get", table: "users", id: 212} и получить ответ {data: {id: 212, firstName: "vasya"}, error: null} или ошибку {data: null, error: "permission_denied"} через http-post и точно также просто получить на сервере и обработать или парится с http-протоколом вспоминая нюансы что для передачи экшна нужно укзать метод GET, а таблицу-айдишник через строку пути /users/212 (причем еще нужно не забыть правильно закодировать) а вместо просто текстовой ошибки нужно вспоминать или искать какой там код в спецификации. И как только экшен который мы хотим передать не нашелся в списке http-методов или для нужной нам ошибки не нету http-кода то уже придется выдумывать собственную схему как передать дополнительные данные. Или пример что если хотим сообщить серверу что кроме юзера нужно вытащить еще и список его папок? Можно конечно пытаться смоделировать через строку запроса типа GET /user/212?include=folders,posts но разве это не получится точно такой же кастомный формат схемы запросов который к тому же нужно парсить и он более ограниченный чем json так почему бы сразу не воспользоваться json-объектами где можно описать любую вложенность? Ну и возможнось очень просто сменить транспорт на вебсокеты не переписывая весь код обработки запросов и ошибок мне кажется тоже немаловажна. > Вебсокетам не нужен rest, он передает не состоение, а message с изменениями от сервера по открытым каналам, это другой тип запросов, и другой способ его обработать. По вебсокетам можно передавать любые данные не только изменения от сервера а и обычные запросы и ответы за данными. Зачем такой разброс когда одни данные будут передаваться по http а другие по вебсокетам не проще ли унифицировать способ общения с сервером и упростить кодовую базу?
Обсуждают сегодня