LINUX.ORG.RU

Урл - для человека или машины?

 ,


0

1

Философский вопрос. Если вместо человекочитаемых урлов типа vasya.com/35/porno/18373 будет vasya.com/{{base64}}, где base64 это жсон пожатый и зашифрованный - это хорошо или одни проблемы при доведении проекта до хоть какой нибудь зрелой стадии?

В общем виде вопрос не имеет правильного ответа. Зависит от проекта и от понимания, нафига это делается. Да, некоторые сайты так и делают. Только там даже не base64, а совсем не расшифровываемая на стороне клиента абракадабра.

В любом случае, главный вопрос, который тут надо задать: зачем?

Если это «жсон пожатый и зашифрованный», то минусы очевидны: больше данных приходится пересылать в обе стороны, данные не кешируются браузером, и их надо каждый раз передавать, если на странице много ссылок, то её объём значительно увеличивается из-за того, что жсон всех этих левых страниц по сути содержится и на странице со ссылками, при том, что кликаться будет только одна.

А в чём плюсы — неочевидно. Вот надо их сформулировать и рассудить, что перевешивает — плюсы или минусы.

CrX ★★★
()
Последнее исправление: CrX (всего исправлений: 2)

base64 там не нужен, можно GUID какой, если ресурс скрытый (приватные ссылки), а ЧПУ (человеко-понятные-урлы) нужны для поисковиков, и надо чтобы они совпадали с заголовком страницы типа /wiki/как-приготовить-черпаху

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

GUID - это Globaly Unique IDentifier

base64 - сама информация, типа нигде хранить не надо

У браузеров ограничение на длину УРЛа. Ты много туда не засунешь. Используй локальное хранилище для этого

rtxtxtrx
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)

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

А то, о чём ты пишешь - это лень и неумение разработчиков нормально проработать проект, продумать систему передачи нужных данных и они придумывают в URL передавать конфиги.

Бред же.

У тебя там джуны работают?

anonymous
()

Сейчас для машины, так как чпу делают для поисковой оптимизации, а не потому что люди смотрят на ссылку перед тем как кликнуть её

cobold ★★★★★
()

Урл должен быть понятным человеку, конечно. Но твои примеры не в тему, из них первый лучше и для человека и для программы. Второй делают не «для кого-то», а когда хотят специально спрятать суть урла от юзеров, тратя на это и свои вычислительные ресурсы.

«Урл для машины», если он не такой как ты в первом варианте написал, будет скорее всего целиком численный - либо вместо слова porno какой-то индекс во внутренней базе сайта, либо вообще одно число вместо пути, которое сквозной индекс сразу к документу. Но пользы «для машины» от всех этих фокусов мало, поэтому лучше оставлять первый вариант.

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

Учитывая, что большинство нынче сидит с телефона, а там урл даже не отображается, пока не начнёшь его редактировать, я сомневаюсь в данном утверждении. У меня и на десктопе в сафари урл не отображается и я как-то не страдаю нисколько от этого.

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

Современные браузеры вообще специфичны, ещё не отображают протокол подключения, в chrome не показывается http:// или https://, даже www.domain.com показывается как domain.com.

В Yandex браузере ещё и Location не показывается, только домен.

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

Их надо беречь от излишней, не понятной информации - а то испугаются.

Я помню как одному отправил в письме ссылку \сервер\департамент\отдел\ на ресурс samba, у него Windows.

Он мне говорит, что открывается, скачать может, но записать нет.

Я спрашиваю, что видите, он мне объясняет и тут я понимаю, что он кликнул по этой ссылке в браузере и chrome её открыл, как просмотр файлов.

Начинаю объяснять, что нужно скопировать эту ссылку и вставить в адресную строку проводника Windows.

У него ступор, ничего не понимает.

Говорю, копируйте и следуйте тому, что я говорю.

  • нажимаете Win + E
  • Нажимаете Ctrl + L
  • Нажимаете Ctrl + V
  • Нажимаете Enter

И это при том, что он мне позвонил и говорит: «Я инженер такого-то отдела».

Ужас.

В общем, всё это отупляет пользователей, а потом получаем вот таких инженеров. Если от пользователя что-то скрывают - он об этом просто так не узнает, если не будет искать в Internet, а если это ему видно, оно работает, то ткнув туда мышью, даже случайно, он будет представлять что есть ещё и location. Интуитивно поймёт зачем это. В браузере аналогично.

anonymous
()

Это какая-то невероятная чушь от человека который никогда с вебом дел не имел. «урл для машины» всегда был и будет в виде querystring, т.е. пары ключ-значение, разделяемые амперсандом https://example.com/page?name=ferret&color=purple

Первое - урлы будут гораздо длиннее.

Параметры page?name=ferret&color=purple в json будут

{
  "page": {
    "name": "ferret",
    "color": "purple"
  }
}

что при кодировании в base64, даже при удалении всех пробельных символов в json, даёт строку размером в 60 байт eyJwYWdlIjp7Im5hbWUiOiAiZmVycmV0IiwiY29sb3IiOiJwdXJwbGUifX0= что не идёт ни в какое сравнение с 29 байтами исходной строки.

И это только для двух параметров, а для большего числа там будут километровые строки.

Второе - вся инфраструктура выстроена под querystring, т.е. во всех вебсерверах запросы по дефолту отправляются и принимаются в этом виде, все GET и POST на любом вебсервере автоматически распарсятся. И не только на сервере, но и в js, в браузерном инспекторе и тд и тп, везде есть встроенные инструменты для работы с этим форматом. Если ты хочешь json и base64 чтобы не парсить человекопонятный урл, то надо брать именно querystring, а не городить свой велосипед.

Третье - это удобно для юзера. Очень легко найти и отредактировать нужный параметр в адресной строке браузера.

Про кэширование и индексацию страниц поисковиками уже написали до меня.

Khronos
()
Последнее исправление: Khronos (всего исправлений: 1)
Ответ на: комментарий от Khronos

Погоди, он же говорит, что сжать и это уже в base64, получается backend должен получить URL, декодировать это в бинарный поток, распаковать и интерпретировать результат как json.

Всё же круто )))

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

Длина строки тут наименьшая из проблем

Ещё раз - сама идея выглядит именно как незнание базового устройства веба. Если конечно ТС от нас не скрывает что ему нужно зашифровать параметры в урле.

ТС пишет что ему нужны вложенные объекты, так в querystring они возможны: table[0][Key]=2&table[0][Value]=2021-11-03T13:37:47&table[1][Key]=1&table[1][Value]=1

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

Ещё раз - сама идея выглядит именно как незнание базового устройства веба.

Я тебя понимаю, я с тобой согласен.

так в querystring они возможны: table[0][Key]=2&table[0][Value]=2021-11-03T13:37:47&table[1][Key]=1&table[1][Value]=1

Тут скорее POST запрос со страницы, чем такая передача, но и она возможна, да.

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

«урл для машины» всегда был и будет в виде querystring, т.е. пары ключ-значение, разделяемые амперсандом https://example.com/page?name=ferret&color=purple

Это всего лишь один из вариантов и не более того. Да, он много где дефолтный по причине своей универсальности (можно передавать что угодно, не привязываясь к деталям устройства приложения), но это ничего не значит.

Второе - вся инфраструктура выстроена под querystring, т.е. во всех вебсерверах запросы по дефолту отправляются

Он не про отправку форм, а про просто урлы.

firkax ★★★★★
()
Ответ на: комментарий от vbr

Я *очень* часто смотрю. И меня аж трисет, когда в современном бравзере не видно текущей ссылки. Регулярно приходится переходить в адресную строку. Чтобы посмотреть номер PR или имя пользователя, репозитория в ГітХабе, например.

urxvt ★★★★★
()

Современные поисковики на это обращают внимание и не читаемую белиберду понижают в выдаче.
Для них foo.bar/baz лучше чем foo.bar/2024-baz.

urxvt ★★★★★
()

Если там есть шифрование, я предполагаю, что есть какой-то пейлоад, который нужно секретно передать/получить от пользователя. Проблемы передавать такой пейлоад не вижу, но зачем сюда же вмешивать и ресурс который запрашивает пользователь? Или сам ресурс тоже секретная информация?

Для публичного сайта, мне кажется, адрес ресурсов нужно хоть в какой-то читаемой форме иметь, а передавать шифрованные данные в GET/POST параметрах, или даже в пути это норма.

Если у тебя в конкретно этом случае в base64 зашифрована ссылка на другую страницу, куда надо редиректнуть пользователя то vasya.ru/{{base64}} это стандарт

masa
()
Последнее исправление: masa (всего исправлений: 1)
Ответ на: комментарий от urxvt

На лоре обычных пользователей нет. Обычный пользователь это соседка баба Нина, которая в браузере смотрит рецепты.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

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

Я же под обычными пользователями имею в виду офисных работников. Они разные бывают.

Остальные, в основном тыкают в смартфон, у них и ПК нет или ноутбука, а тем кто работает за ПК или ноутбуком как раз важен УРЛ по большей части.

Используемая техника показывает уровень требований пользователя к фунционалу и его навыки.

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

баш кортянкой с курл запросом, типа

Бро зацени прикол, вот ссылка :D

curl 'https://www.google.com/gen_204?atyp=i&ei=_CxBZqLAGNOA6As&ct=slh&v=t1&im=M&pv=0.21070805906102685&me=218:1715547393167,R,1,CBIQAA,230,811,652,107:0,R,1,CBEQAA,230,919,652,107:0,R,1,CAEQAA,958,165,372,2383:0,R,1,CD4QAA,937,165,393,1278:0,R,1,CD0QAA,938,165,392,72:0,R,1,CD4QBg,938,237,392,1109:0,R,1,CE4QAA,938,237,392,1109:0,R,1,CFMQAA,958,237,372,322:0,R,1,CEIQ9,173,158:2594,V,0,0,1880,509:0,R,3,0,958,145,569,364:0,R,3,1,958,145,569,364:316,h,3,1,o:0,h,3,0,o:1384,e,B&zx=1715547397465&opi=89978449' -X POST -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate, br' -H 'Referer: https://www.google.com/' -H 'Origin: https://www.google.com' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: 1P_JAR=2024-05-12-20; '

В случае base64 в урле, будет не лучше.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)

Это бред маркетологов, никто из простых людей не пользуется строкой браузера для переходов и тем более отправки гетзапроса, этим пользуются либо программисты, либо пауки, конечный пользователь даже домен не проверяет, из-за чего так распространен фишинг. Грубо говоря, пофиг, category/blabla у тебя или 6gfrg433vvd/74rgrcwqyhouuttb543v

skidphysic
()

Есть сила, которая стремится сделать веб структурированной коллекцией структурированных документов на стандартизированных языках разметки. В силу каких-то своих мимолетных причуд поисковики сейчас действуют солидарно с этой силой, продвигая в выдаче URL вида vasya.com/porn/brunettes/milf/ по сравнению с vasya.com/object9876543.

Ей противостоит другая сила, которая предпочла бы по адресу vasya.com выдавать сразу флеш-приложение и гнать контент только через него, не выдавая наружу вообще никаких ссылок или ID.

На чьей стороне быть – решать тебе :)

Zeta_Gundam
()

1. SEO. Поисковики повышают позицию в выдаче страниц, у которых URL человекочитаемый (содержит ключевые слова).

2. URL таки может быть перепечатываться юзером вручную (например, с офлайн рекламных материалов).

3. Некоторые социальные платформы, где ты можешь размещать ссылки на страницы своего сайта, могут отображать ссылки в текстах материалов как есть. И длинная абракадабра будет портить внешний вид материала и уменьшать конверсию. Или может вообще не влезть в ограничения на длину сообщения (а сократители ссылок тоже понижают конверсию, плюс у юзеров не маячит перед глазами домен сайта и это тоже плохо).

Короче, для какого-нибудь SPA ты можешь пихать в URL всё что-угодно. Для блогов, новостей и порно-сайтов - URL должен быть коротким и по возможности человекочитаемым.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 3)
Ответ на: комментарий от KivApple

SEO. Поисковики повышают позицию в выдаче страниц, у которых URL человекочитаемый (содержит ключевые слова).

Старый миф. Давно уже похер

anonymous
()

Так называемые человекопонятные URL придумали SEO-петушки вовсе не для людей, а для поисковых роботов. Так что не бывает URL «для людей». Это такой же эвфемизм, как дисковая операционная система.

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

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

чтобы вталдычить бухгалтером, что ссылка nalogi.awsapps.com в письме с требованием погасить налоговую задолженность, нихрена не связана с сайтом налоговой, пришлось попотеть :)
для них всё технически сложная и нирена непонятная белиберда.

так что замудрения с человекочитаемым урлом никому неинтересны.

pfg ★★★★★
()

И для человека(админа) и для машины. Если url полностью состоит из билеберды, то искать проблемы в логах очень не удобно, да и в принципе понимать что где к чему удобнее, когда есть подобие логического пути. Но если хочется в сам урл занести параметры в base64, то почему бы и нет.

vtVitus ★★★★★
()

на ум приходит пока только такой возможный, и конечно искусственный, сценарий, когда нечто подобное могло бы понадобиться. Предположим, у нас есть сервис обмена ссылками (да хоть просто форум на котором можно постить чужие ссылки), и мы хотим скрыть от юзеров потенциально ненормативный контент - не хотим чтобы на нашей странице отображалось слово «жопа» которое есть в урле со стороннего сайта, но хранить все шареные урлы в базе данных мы тоже не хотим.

FishHook
()

Я опытным путем установил, что максимальная длина URL в последнем Chromium равна 512000 символов, те, да, ты можешь закодировать в нем целую страницу, но ест-но без картинок, да и ссылку на нее в телегу не кинешь, обрежет.

Для тестирования генерируем ссылку в консоли [браузера]:

> 'https://www.google.com/search?q=' + 'x'.repeat((2 << 24) - 32) // так ссылка ровно 32 мегабайта получится

Переходим по ней и смотрим насколько он ее обрезал:

location.href.length
rtxtxtrx
()
Последнее исправление: rtxtxtrx (всего исправлений: 4)