Новое сообщение в форум Веб программирование

Форум	Веб программирование
Тема	Как правильно задавать вопросы

Здравствуйте, okman, Вы писали:

O>Здравствуйте, Sinclair, Вы писали:

S>>Философия: Искусственно разделять слои в приложениях не нужно.

O>Разделять слои в приложениях нужно не искусственно, а естественно.

S>>Полное использование возможностей нижележащего протокола - вот путь к успеху. Не надо слишком думать о том, что будет, если мы заменим транспортный протокол.

O>Пример - веб-сервис может использовать HTTP для браузеров и бинарный протокол для других программ-клиентов.
O>Очевидно, что реализовать такое будет проще, если транспорт и логика протокола будут четко разделены.

O>>>Коды состояний HTTP не смогут обеспечить клиента точной информацией о том, на каком этапе обработки запроса
O>>>произошел сбой - на транспортном или логическом. Если, к примеру, и front end, и back end сервера могут
O>>>отдавать "500 Internal Server Error", то рано или поздно наступает ситуация, когда клиент получает такой
O>>>ответ и не знает, от кого именно он пришел и по каким правилам обрабатывать его содержимое.

S>>Отлично. Ну, вот расскажите мне, по каким правилам нужно обрабатывать ответ 500 Internal Server Error, в зависимости от того, кто его вернул.

O>Вопрос не понят. При таком подходе, который я защищаю, "500 Internal Server Error" может вернуть
O>только фронт энд сервера. Если, копаясь в логах сервера в поисках какой-нибудь непонятной ошибки, я
O>нахожу код 500, то точно знаю, что до бэк энда дело вообще не дошло. И для этого мне не обязательно
O>вытаскивать тело ответа сообщения (которое, кстати, может быть сжато gzip-ом) или еще что-то.

S>>В моей реальности клиент видит 500, и ему всё равно, откуда он взялся.

O>Правильно ли я понял, что в Вашей реальности несущественно, произошла ли ошибка передачи данных
O>или логическая ошибка самого сервиса ?

O>Могу только прокомментировать, что системы и требования к ним бывают разные, но в тех, где мне
O>довелось поучаствовать, такое разделение практически всегда имело большой смысл.

O>>>"надпротокольные" сообщения об ошибках, возвращенные с кодом 200, могут быть и более структуированными, и
O>>>более информативными, и вообще более соответствующими духу системы, в которой они используются.

S>>И вот как раз это - очень плохо. Потому, что в рамках протокола вы не даёте никакой информации о семантике.

O>Потому что в описываемой модели работа протокола-транспорта на данном этапе закончена - сообщение доставлено.
O>Остальным занимается прикладной протокол, расположенный выше.

S>>Например, прокси-сервер будет искренне полагать, что всё в порядке, и кэшировать результат такой ошибки.

O>Прокси может кэшировать и другие ответы. Так что данная проблема имеет малое отношение к вопросу.
O>Ну и есть же "pragma: no-cache".

S>>Нужно вкладывать "более структурированные" и "более информативные" данные внутрь протокола,
S>>выбирая код статуса сообразно семантике ответа.

O>Какие средства предоставляет HTTP для передачи структурированной информации об ошибке ?

S>>А про "соответствие духу системы", я имею ровно противоположное мнение. Либо дух системы соответствует духу HTTP, тогда грех этим не воспользоваться. Либо дух системы противоречит духу HTTP - тогда мы имеем мертворожденного мутанта, вроде SOAP, авторов которого нужно судить за преступления против технического совершенства.

O>Да, судить за преступления. И уволить. А еще перед этим расстрелять.

O>Если надумаете ответить, напишите вот о чем - почему, когда я пытаюсь залогиниться на RSDN, используя
O>неправильный пароль, сервер не выкидывает мне "401 Unauthorized" или "403 Forbidden" ?

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail