#ссылка дня
Пятничных котов вам в ленту! Но просто котов вы можете найти где угодно, тут же — HTTP-коты: https://http.cat/
Знать коды протокола HTTP должен каждый веб-разработчик, чтобы не попадать в глупые ситуации и правильно пользоваться API. А раз их можно выучить, глядя на котов, почему бы и нет.
#http #handbook
Пятничных котов вам в ленту! Но просто котов вы можете найти где угодно, тут же — HTTP-коты: https://http.cat/
Знать коды протокола HTTP должен каждый веб-разработчик, чтобы не попадать в глупые ситуации и правильно пользоваться API. А раз их можно выучить, глядя на котов, почему бы и нет.
#http #handbook
#ссылка дня
Воскресных котов вам в ленту! Но просто котов вы можете найти где угодно, тут же — HTTP-коты: https://http.cat/
Знать коды протокола HTTP должен каждый веб-разработчик, чтобы не попадать в глупые ситуации и правильно пользоваться API. А раз их можно выучить, глядя на котов, почему бы и нет.
#http #handbook
Воскресных котов вам в ленту! Но просто котов вы можете найти где угодно, тут же — HTTP-коты: https://http.cat/
Знать коды протокола HTTP должен каждый веб-разработчик, чтобы не попадать в глупые ситуации и правильно пользоваться API. А раз их можно выучить, глядя на котов, почему бы и нет.
#http #handbook
🥰13👍9🔥2😁2👎1
#ссылка дня
Воскресных котов вам в ленту! Но просто котов вы можете найти где угодно, тут же — HTTP-коты: https://http.cat/
Знать коды протокола HTTP должен каждый веб-разработчик, чтобы не попадать в глупые ситуации и правильно пользоваться API. А раз их можно выучить, глядя на котов, почему бы и нет.
#http #handbook #бородач
Воскресных котов вам в ленту! Но просто котов вы можете найти где угодно, тут же — HTTP-коты: https://http.cat/
Знать коды протокола HTTP должен каждый веб-разработчик, чтобы не попадать в глупые ситуации и правильно пользоваться API. А раз их можно выучить, глядя на котов, почему бы и нет.
#http #handbook #бородач
😁13🦄2
#фишка дня
Позавчера вышел Chrome 117. И по его поводу надо бы написать пост побольше. Ну хотя бы по той причине, что там появились сабгриды!
Наш властелин гридов, думаю, будет рад.
CSS Subgrid были внедрены в Firefox 2 декабря 2019 года, а в Safari — 11 сентября 2022 года. Я специально так растягиваю даты, чтобы вы насладились отставанием Хрома от недооценённых конкурентов.
Edge ещё тупит, но он по факту тоже Хром на свистоперделках, так что скоро, скоро.
Ну а фишка дня — наконец-то для понимания HTTP-кодов вам не придётся смотреть на котов! Какой каламбур, ня.
Они теперь прописаны прямо в описании запроса на вкладке Network.
Почему это важно?
Ну, например, потому что больше и больше сервисов начинают правильно их использовать, а их фронтенды — правильно им подчиняться. Так что всплывает множество не самых ожидаемых кодов.
Всем коданы, котаны!
#http #chrome #subgrid
Позавчера вышел Chrome 117. И по его поводу надо бы написать пост побольше. Ну хотя бы по той причине, что там появились сабгриды!
Наш властелин гридов, думаю, будет рад.
CSS Subgrid были внедрены в Firefox 2 декабря 2019 года, а в Safari — 11 сентября 2022 года. Я специально так растягиваю даты, чтобы вы насладились отставанием Хрома от недооценённых конкурентов.
Edge ещё тупит, но он по факту тоже Хром на свистоперделках, так что скоро, скоро.
Ну а фишка дня — наконец-то для понимания HTTP-кодов вам не придётся смотреть на котов! Какой каламбур, ня.
Они теперь прописаны прямо в описании запроса на вкладке Network.
Почему это важно?
Ну, например, потому что больше и больше сервисов начинают правильно их использовать, а их фронтенды — правильно им подчиняться. Так что всплывает множество не самых ожидаемых кодов.
Всем коданы, котаны!
#http #chrome #subgrid
👍17❤4🤩2
#фишка дня
Сейчас возвращается мода (и, по-моему, это правильно) на сохранение состояния вашего веб-приложения в адресной строке браузера.
Буквально — используя параметры строки запроса (query string parameters).
Ну то есть что-то вроде
А вот как позволить клиенту обновить страницу, сохранив эти параметры? Желательно, без лишней работы и без использования JS вообще.
А очень просто!
Да, вот так просто! Самое классное, что абсолютно валидно и есть в спеках: https://stackoverflow.com/questions/5637969/is-an-empty-href-valid/43340108#43340108
В спеке буквально прописано, что такая ссылка ведёт на текущий документ, со всеми его параметрами запроса.
Не пишите лишнего, котаны!
#http #html #trick
Сейчас возвращается мода (и, по-моему, это правильно) на сохранение состояния вашего веб-приложения в адресной строке браузера.
Буквально — используя параметры строки запроса (query string parameters).
Ну то есть что-то вроде
https://buy.that?title=Product&action=buy&config=2&amount=3, классические GET-параметры, но управляемые с фронта.А вот как позволить клиенту обновить страницу, сохранив эти параметры? Желательно, без лишней работы и без использования JS вообще.
А очень просто!
<a href="">Reload</a>Да, вот так просто! Самое классное, что абсолютно валидно и есть в спеках: https://stackoverflow.com/questions/5637969/is-an-empty-href-valid/43340108#43340108
В спеке буквально прописано, что такая ссылка ведёт на текущий документ, со всеми его параметрами запроса.
Не пишите лишнего, котаны!
#http #html #trick
👍49❤2
#фишка дня
Сейчас возвращается мода (и, по-моему, это правильно) на сохранение состояния вашего веб-приложения в адресной строке браузера.
Буквально — используя параметры строки запроса (query string parameters).
Ну то есть что-то вроде
А вот как позволить клиенту обновить страницу, сохранив эти параметры? Желательно, без лишней работы и без использования JS вообще.
А очень просто!
Да, вот так просто! Самое классное, что абсолютно валидно и есть в спеках: https://stackoverflow.com/questions/5637969/is-an-empty-href-valid/43340108#43340108
В спеке буквально прописано, что такая ссылка ведёт на текущий документ, со всеми его параметрами запроса.
Не пишите лишнего, котаны!
#http #html #trick #бородач
Сейчас возвращается мода (и, по-моему, это правильно) на сохранение состояния вашего веб-приложения в адресной строке браузера.
Буквально — используя параметры строки запроса (query string parameters).
Ну то есть что-то вроде
https://buy.that?title=Product&action=buy&config=2&amount=3, классические GET-параметры, но управляемые с фронта.А вот как позволить клиенту обновить страницу, сохранив эти параметры? Желательно, без лишней работы и без использования JS вообще.
А очень просто!
<a href="">Reload</a>Да, вот так просто! Самое классное, что абсолютно валидно и есть в спеках: https://stackoverflow.com/questions/5637969/is-an-empty-href-valid/43340108#43340108
В спеке буквально прописано, что такая ссылка ведёт на текущий документ, со всеми его параметрами запроса.
Не пишите лишнего, котаны!
#http #html #trick #бородач
❤22👍19
#статья дня
Встроенная в браузеры функция выполнения HTTP-запросов
Топорная, если хотите.
Ошибки бросает только на ошибках сервера или соединения (404 — не ошибка), нужно самому формировать заголовки запроса, даже самому формировать строку с JSON или данными формы в urlencode...
Очень многие вместо неё как использовали, так и продолжают использовать тот же axios, кто-то берёт разные иные обёртки, как Tanstack Query aka React Query, а кто-то один раз написал свою реализацию обработки ошибок и прочего бойлерплейта — и забыл.
Так вот, позвольте вам напомнить, что таки есть причина для этой кондовости. По-порядку.
Чаще всего получение данных сводится к разрешению двух промисов:
Но почему? Почему fetch сразу данные-то не отдаёт? К чему эти танцы?
Так вот, всё дело в том, что мир не ограничивается гонянием джисонов по сети. Возможно, нужен просто текст. Возможно, решение нужно принять ещё до того, как заняться обработкой тела запроса. Возможно, бинарные данные. А, возможно, данные кусками или потоком — stream — который можно прервать в любой момент:
В любом случае, так или иначе, собственно, fetch возвращает промис с результатами запроса, а уже потом — дело за вами, как его обработать.
И вот хороший пример — от Тома Стивена: https://tomontheinternet.com/why-two-awaits/
В статье он даёт ссылку на код с демонстрацией: https://github.com/tom-on-the-internet/fetch-demonstration
Ну и я решил и в песочницу этот код запихать, для наглядности и понимания процесса: https://codesandbox.io/p/devbox/mvhrgz
Так что, возможно,
#fetch #http #stream
Встроенная в браузеры функция выполнения HTTP-запросов
fetch — штука достаточно кондовая. Топорная, если хотите.
Ошибки бросает только на ошибках сервера или соединения (404 — не ошибка), нужно самому формировать заголовки запроса, даже самому формировать строку с JSON или данными формы в urlencode...
Очень многие вместо неё как использовали, так и продолжают использовать тот же axios, кто-то берёт разные иные обёртки, как Tanstack Query aka React Query, а кто-то один раз написал свою реализацию обработки ошибок и прочего бойлерплейта — и забыл.
Так вот, позвольте вам напомнить, что таки есть причина для этой кондовости. По-порядку.
Чаще всего получение данных сводится к разрешению двух промисов:
let response = await fetch("/some-url")
let myObject = await response.json()
Но почему? Почему fetch сразу данные-то не отдаёт? К чему эти танцы?
Так вот, всё дело в том, что мир не ограничивается гонянием джисонов по сети. Возможно, нужен просто текст. Возможно, решение нужно принять ещё до того, как заняться обработкой тела запроса. Возможно, бинарные данные. А, возможно, данные кусками или потоком — stream — который можно прервать в любой момент:
async function readData(url) {
const response = await fetch(url);
for await (const chunk of response.body) {
// Do something with each "chunk"
}
// Exit when done
}
В любом случае, так или иначе, собственно, fetch возвращает промис с результатами запроса, а уже потом — дело за вами, как его обработать.
И вот хороший пример — от Тома Стивена: https://tomontheinternet.com/why-two-awaits/
В статье он даёт ссылку на код с демонстрацией: https://github.com/tom-on-the-internet/fetch-demonstration
Ну и я решил и в песочницу этот код запихать, для наглядности и понимания процесса: https://codesandbox.io/p/devbox/mvhrgz
Так что, возможно,
fetch хорош таким, какой он есть. Универсальным.#fetch #http #stream
👍17❤2
#ссылка дня
Пятничных котов вам в ленту! Но просто котов вы можете найти где угодно, тут же — HTTP-коты: https://http.cat/
Знать коды протокола HTTP должен каждый веб-разработчик, чтобы не попадать в глупые ситуации и правильно пользоваться API. А раз их можно выучить, глядя на котов, почему бы и нет.
#http #handbook #бородач
Пятничных котов вам в ленту! Но просто котов вы можете найти где угодно, тут же — HTTP-коты: https://http.cat/
Знать коды протокола HTTP должен каждый веб-разработчик, чтобы не попадать в глупые ситуации и правильно пользоваться API. А раз их можно выучить, глядя на котов, почему бы и нет.
#http #handbook #бородач
🤩9❤5👍1
#ссылка дня
Наверное, стоило прислать это сразу после пятничных котов :)
Итак, вашему вниманию: диаграмма разрешения кодов HTTP.
Тут: https://github.com/for-GET/http-decision-diagram?tab=readme-ov-file
Разрешения не в смысле "можно ли", а в смысле процесса принятия решения, когда какой код уместен.
Она довольно большая и основывается на большом количестве RFC: RFC7230, RFC7231, RFC7232, RFC7233, RFC7234 RFC7235.
Ну и там, где в спецификациях оставлены пробелы — дополняет.
Всё весьма хорошо укладывается в голове.
#http #diagram
Наверное, стоило прислать это сразу после пятничных котов :)
Итак, вашему вниманию: диаграмма разрешения кодов HTTP.
Тут: https://github.com/for-GET/http-decision-diagram?tab=readme-ov-file
Разрешения не в смысле "можно ли", а в смысле процесса принятия решения, когда какой код уместен.
Она довольно большая и основывается на большом количестве RFC: RFC7230, RFC7231, RFC7232, RFC7233, RFC7234 RFC7235.
Ну и там, где в спецификациях оставлены пробелы — дополняет.
Всё весьма хорошо укладывается в голове.
#http #diagram
👍10❤3🫡1
#фишка дня
Сейчас возвращается мода (и, по-моему, это правильно) на сохранение состояния вашего веб-приложения в адресной строке браузера.
Буквально — используя параметры строки запроса (query string parameters).
Ну то есть что-то вроде
А вот как позволить клиенту обновить страницу, сохранив эти параметры? Желательно, без лишней работы и без использования JS вообще.
А очень просто!
Да, вот так просто! Самое классное, что абсолютно валидно и есть в спеках: https://stackoverflow.com/questions/5637969/is-an-empty-href-valid/43340108#43340108
В спеке буквально прописано, что такая ссылка ведёт на текущий документ, со всеми его параметрами запроса.
Не пишите лишнего, котаны!
#http #html #trick #бородач
Сейчас возвращается мода (и, по-моему, это правильно) на сохранение состояния вашего веб-приложения в адресной строке браузера.
Буквально — используя параметры строки запроса (query string parameters).
Ну то есть что-то вроде
https://buy.that?title=Product&action=buy&config=2&amount=3, классические GET-параметры, но управляемые с фронта.А вот как позволить клиенту обновить страницу, сохранив эти параметры? Желательно, без лишней работы и без использования JS вообще.
А очень просто!
<a href="">Reload</a>Да, вот так просто! Самое классное, что абсолютно валидно и есть в спеках: https://stackoverflow.com/questions/5637969/is-an-empty-href-valid/43340108#43340108
В спеке буквально прописано, что такая ссылка ведёт на текущий документ, со всеми его параметрами запроса.
Не пишите лишнего, котаны!
#http #html #trick #бородач
👍22❤4🤩1
#новость дня
В HTTP появился (точнее, вот-вот появится, только RFC приняли) новый метод QUERY.
Примерно такой:
И самое интересное тут даже не то, что теперь можно отправлять сложный поисковый запрос в теле HTTP-запроса. Самый интересный вопрос: а разве мы не могли делать это через GET?
Могли. Иногда даже делали.
На уровне HTTP-сообщения тело у GET возможно. Протокол не развалится только потому, что после заголовков пришёл body.
Проблема в другом: у тела GET нет нормальной общей семантики.
Стандарт не говорит: «тело GET — это параметры запроса». Сервер и клиент могут между собой так договориться, но для остальной инфраструктуры это будет частная магия. Прокси, CDN, кэши, балансировщики, библиотеки и браузерные API не обязаны понимать такой договор.
Поэтому GET с body — это поведение из серии “может работать в нашей связке”. Где-то пройдёт, где-то тело проигнорируют, где-то запрос завернут, а где-то его вообще нельзя будет отправить. Например, браузерный
QUERY как раз стандартизирует этот сценарий.
Смысл метода: это запрос на чтение, но параметры запроса лежат в теле. То есть больше не нужно притворяться, что сложный фильтр — это короткая строка query-параметров, и не нужно использовать POST там, где состояние на сервере не меняется.
От POST отличие тоже важное. POST для HTTP-инфраструктуры выглядит как метод с возможными побочными эффектами. QUERY, наоборот, описан как safe и idempotent: его можно повторить, не ожидая, что повтор сам по себе что-то создаст или изменит.
Получается, QUERY — это не «GET с body», а нормальный стандартный способ сказать: тело запроса важно, оно описывает выборку, и сам запрос при этом остаётся запросом на чтение.
#http
В HTTP появился (точнее, вот-вот появится, только RFC приняли) новый метод QUERY.
Примерно такой:
QUERY /search
Content-Type: application/json
{
"q": "foo",
"limit": 10,
"sort": "-published"
}
И самое интересное тут даже не то, что теперь можно отправлять сложный поисковый запрос в теле HTTP-запроса. Самый интересный вопрос: а разве мы не могли делать это через GET?
Могли. Иногда даже делали.
GET /search
Content-Type: application/json
{
"q": "foo",
"limit": 10,
"sort": "-published"
}
На уровне HTTP-сообщения тело у GET возможно. Протокол не развалится только потому, что после заголовков пришёл body.
Проблема в другом: у тела GET нет нормальной общей семантики.
Стандарт не говорит: «тело GET — это параметры запроса». Сервер и клиент могут между собой так договориться, но для остальной инфраструктуры это будет частная магия. Прокси, CDN, кэши, балансировщики, библиотеки и браузерные API не обязаны понимать такой договор.
Поэтому GET с body — это поведение из серии “может работать в нашей связке”. Где-то пройдёт, где-то тело проигнорируют, где-то запрос завернут, а где-то его вообще нельзя будет отправить. Например, браузерный
fetch не разрешает body у GET и HEAD.QUERY как раз стандартизирует этот сценарий.
QUERY /search
Content-Type: application/json
{
"q": "foo",
"limit": 10,
"sort": "-published"
}
Смысл метода: это запрос на чтение, но параметры запроса лежат в теле. То есть больше не нужно притворяться, что сложный фильтр — это короткая строка query-параметров, и не нужно использовать POST там, где состояние на сервере не меняется.
От POST отличие тоже важное. POST для HTTP-инфраструктуры выглядит как метод с возможными побочными эффектами. QUERY, наоборот, описан как safe и idempotent: его можно повторить, не ожидая, что повтор сам по себе что-то создаст или изменит.
Получается, QUERY — это не «GET с body», а нормальный стандартный способ сказать: тело запроса важно, оно описывает выборку, и сам запрос при этом остаётся запросом на чтение.
#http
👍19❤5