Телеграмм чат группы nodejs

А при чем тут дока... Мы сейчас говорим о причинах, почему строгое следование заголовкам не является достаточным

Что вам в 404 не понятно? Страница или документ не найден

00:19пожаловаться #1

AZ

Если API _очень_ простое (вот прям запрос-ответ, даже без состояния) типа поллинга чего-то – то может и можно вообще одними статусами обойтись.

Но если это JSON-апи – то можно сделать ответ сколь угодно подробным!

Если детализация есть в ответе - то на кой вообще фиг нужно читать заголовок =))) А соответственно целесообразность исключений и т.п. сразу существенно снижается. Как уже говорил - это требуется только в том случае, если ответ не парсится (ответил NGINX простым html, а не бек JSON-ом).

00:19пожаловаться #2

AZ

Что вам в 404 не понятно? Страница или документ не найден

А вы вообще в теме дискуссии?

Алексей Клименко... in Node.js — русскоговорящее сообщество

00:20пожаловаться #3

АК

Если детализация есть в ответе - то на кой вообще фиг нужно читать заголовок =))) А соответственно целесообразность исключений и т.п. сразу существенно снижается. Как уже говорил - это требуется только в том случае, если ответ не парсится (ответил NGINX простым html, а не бек JSON-ом).

В моём случае можно проверять, а можно не проверять (так как в JSON будет код fatal_error, и на нём можно сделать throw message).

Либо проверить код, и сделать throw на любом кроме 200 без чтения тела ответа, если фронт всё равно ничего разумного с ним сделать не сумеет.

00:22пожаловаться #4

AZ

В моём случае можно проверять, а можно не проверять (так как в JSON будет код fatal_error, и на нём можно сделать throw message).

Либо проверить код, и сделать throw на любом кроме 200 без чтения тела ответа, если фронт всё равно ничего разумного с ним сделать не сумеет.

в твоем случае да, т.к. только 200 выдает корректный JSON от бека, а все остальное - это заведомо ошибки, источник которых в системе (нгинк/сервис/сервер/роутер/файрвол и т.д. - что угодно, короче)

Artem Soroka in Node.js — русскоговорящее сообщество

00:24пожаловаться #5

AS

Если детализация есть в ответе - то на кой вообще фиг нужно читать заголовок =))) А соответственно целесообразность исключений и т.п. сразу существенно снижается. Как уже говорил - это требуется только в том случае, если ответ не парсится (ответил NGINX простым html, а не бек JSON-ом).

Если из заголовка понятно, что данных нет, зачем читать тело ответа, парсить json?

00:24пожаловаться #6

AZ

Если из заголовка понятно, что данных нет, зачем читать тело ответа, парсить json?

Например, чтобы показать юзеру, что не найден запрошенный юзер, а не то, что было обращение к несуществующему роуту...

00:25пожаловаться #7

AZ

/api/user/12345 - 404 - ибо роут неверный
/api/users/12345 - 404 - ибо юзера не существует

верх идиотизма

Artem Soroka in Node.js — русскоговорящее сообщество

00:26пожаловаться #8

AS

Например, чтобы показать юзеру, что не найден запрошенный юзер, а не то, что было обращение к несуществующему роуту...

А почему должно быть обращение к не существующему url? Тестировать проект стоит до публикации ))

Алексей Клименко... in Node.js — русскоговорящее сообщество

00:26пожаловаться #9

АК

Например, чтобы показать юзеру, что не найден запрошенный юзер, а не то, что было обращение к несуществующему роуту...

Просто бывают деструктивные действия.

Например, функция, которая собирает списки пользователей – она может удалять у себя тех юзеров из локального списка, которых больше нет в базе.

И при банальной перезагрузке сервера – по «ошибкам» подумать, что пользователей нет вообще, и всё стереть.

00:27пожаловаться #10

AZ

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

Алексей Клименко... in Node.js — русскоговорящее сообщество

00:27пожаловаться #11

АК

А почему должно быть обращение к не существующему url? Тестировать проект стоит до публикации ))

Версия программы на сервере сменилась, а мы зашли со старого (_очень_ старого!) клиента. Возможно, на несуществующий URL вообще.

Artem Soroka in Node.js — русскоговорящее сообщество

00:28пожаловаться #12

AS

Версия программы на сервере сменилась, а мы зашли со старого (_очень_ старого!) клиента. Возможно, на несуществующий URL вообще.

Обратная совсестимость, не?
api/v1/users там все дела?

00:29пожаловаться #13

AZ

Версия программы на сервере сменилась, а мы зашли со старого (_очень_ старого!) клиента. Возможно, на несуществующий URL вообще.

Бесполезно, человек живет с идеальном мире, где все тестят досконально, никто не ошибается, и не существует публичного/внешнего апи, к которому могут подключаться/использовать другие люди. А если и есть, то там сидят гениальные разрабы и тестеры, которые тоже не допускают ошибок и потому не мучают саппорт тупыми вопросами ;)

00:30пожаловаться #14

AZ

мне в такой =(((( пдарите билетик, а?

00:30пожаловаться #15

AZ

Обратная совсестимость, не?
api/v1/users там все дела?

FB, VK - это им скажите, они очень старые версии своего АПИ со временем вырубают =))))

00:31пожаловаться #16

AZ

видимо, не слышали про совместимость обратную... надо расказать, может на лида позовут

Artem Soroka in Node.js — русскоговорящее сообщество

00:31пожаловаться #17

AS

Бесполезно, человек живет с идеальном мире, где все тестят досконально, никто не ошибается, и не существует публичного/внешнего апи, к которому могут подключаться/использовать другие люди. А если и есть, то там сидят гениальные разрабы и тестеры, которые тоже не допускают ошибок и потому не мучают саппорт тупыми вопросами ;)

Мы живем в неидеальном мире, поэтому тестим как папа Карло, жестко и долго ))

Алексей Клименко... in Node.js — русскоговорящее сообщество

00:31пожаловаться #18

АК

Обратная совсестимость, не?
api/v1/users там все дела?

Однажды в VK API я случайно не передавал параметр v – версия апи – в одном из запросов.

Через полгода мой скрипт перестал работать.
Добавил. Заработал снова.

~ in Node.js — русскоговорящее сообщество

00:32пожаловаться #19

~

здравствуйте, скиньте пожалуйста ссылку на php русс