Id url: Использование ID в URL | AppMaster

Leave a Comment / Разное / By /

Использование ID в URL | AppMaster

Использования одних только глобальных переменных недостаточно, чтобы закрыть все потребности  — мы не сможем дать ссылку на выбранную запись. Ведь значение переменной хранится только в той вкладке браузера, где оно было установлено. Для решения этой проблемы есть возможность записать необходимую информацию прямо в URL и передавать точную ссылку на конкретный элемент.

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

Настройки страницы

В первую очередь необходимо изменить адрес страницы с таблицей городов. Для этого нужно открыть настройки соответствующего пункта меню и указать переменную :id в адресе URL.


Дальше нужно настроить навигацию, которая должна не просто переходить на указанную страницу, но и добавлять параметр ID в URL. Для этого вернемся к таблице со списком стран и настроим действия по триггеру onRowDoubleClick. Теперь при двойном клике по строке таблицы будет происходить навигация на страницу, в адресе которой будет указан ID выбранной записи.


Бизнес процесс для получения ID из URL

Следующий шаг — это получение данного ID из URL. Данная возможность может понадобиться в самых разных бизнес-процессах, поэтому наилучшим решением станет создание отдельной функции для нее. Ее можно создать в соответствующей вкладке раздела web-приложений. При этом, в отличие от бизнес-процессов, которые ранее создавали для бэкенда, она будет выполняться не на сервере, а непосредственно на устройстве того пользователя, который ее запустил.


В БП используем следующие блоки:

  • Get Current Page, для получения текущего URL.
  • Split string, чтобы разбить URL на отдельные блоки, выбрав “/” в качестве разделителя.
  • Для конкретной страницы мы могли бы сразу указать нужный String из полученного массива по его индексу. Но бизнес-процесс универсальный и может использоваться для URL другой структуры, поэтому лучше немного усложнить логику. Проверим количество элементов String в массиве после разбивки с помощью блока Array size.
  • Блоком Subtract вычтем 3 из получившегося количества (наш элемент является вторым с конца, а сама нумерация индексов начинается с 0)
  • Передадим вычисленное значение в качестве индекса в блок Array Element, для получения необходимого String из массива
  • Сделаем итоговое преобразование String в Integer.


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


Postback URL источника трафика

Postback URL источника трафика

Suggest Edits

❗️

ДАННАЯ СТАТЬЯ БОЛЕЕ НЕ АКТУАЛЬНА. МЫ ПЕРЕЕЗЖАЕМ В ИНТЕРКОМ!
http://help-center.peerclick.com/ru
ПРИСОЕДИНЯЙТЕСЬ И НАХОДИТЕ ВСЮ АКТУАЛЬНУЮ ИНФОРМАЦИЮ ПО РАБОТЕ С PEERCLICK!

S2S Postback URL позволяет отправлять данные с одного сервера на другой, запрашивая уникальный URL с помощью HTTP метода (GET или POST). В PeerClick Postback запрос к источнику трафика выполняется, когда конверсия успешно зарегистрирована в кампании PeerClick.

Обычно Postback URL включает в себя уникальные параметры, установленные источником для отправки определенных переменных данных по запросу. Наиболее распространенная переменная данных, отправляемая в любом запросе Postback, — это Click ID. Click ID — это случайные буквенно-цифровые строки, генерируемые источниками трафика для уникальной идентификации и записи входящих и исходящих пользователей (кликов). Кроме того, идентификаторы кликов используются в качестве стандартного метода для отслеживания уникального события конверсии для каждого пользователя.

В настроенном источнике трафика в PeerClick ClickID токен обычно отображается в поле External ID в разделе Параметры. Значения, указанные в полях Параметр и Заполнитель, взяты из источника трафика. Если вы используете шаблон источника трафика, предлагаемый PeerClick, то значения будут автоматически заполняться при загрузке шаблона. Если вы настроили свой собственный источник трафика, вам нужно найти данную информацию в документации источника трафика. Кроме того, необходимо помнить, что некоторые источники трафика могут не отправлять переменную Click ID.

Все

click ID, отправленные источником трафика, записываются как external ID в PeerClick. Затем , поддерживаемый в PeerClick токен {external_id}, должен динамически пересылать значение Click ID на определенный Postback URL после успешной регистрации конверсии.

Вместо глобального параметра Postback URL, основанного исключительно на параметре Click ID, некоторые источники требуют, чтобы другие параметры, например ID учетной записи или ID кампании, также отображались в поддерживаемых Postback URL.

Пример:
Ниже вы можете найти пример, как правильно определить Postback URL источника трафика, где есть два параметра: clickid и параметр ClickID учетной записи.
Источник трафика 50onRed использует Postback URL для конкретной учетной записи. Специфичный Postback URL для учетной записи обычно содержит как параметр

clickid, так и параметр ClickID учетной записи:
http://www.trkjmp.com/conv?v=REPLACE&c={external_id}

где:

  • c: это параметр, который используется для передачи информации об уникальной конверсии события для каждого пользователя

  • {externali_d}: токен PeerClick, который должен быть сопоставлен с параметром, отправляющим информацию об успешных конверсиях

  • v: Это ID параметр учетной записи, который обязательно должен быть включен в Postback URL, если вы хотите установить 50onRed в качестве источника трафика

REPLACE: это строка запроса, которая должна быть заменена значением, специально предоставленным вам от источника трафика 50onRed;

Для правильной работы Postback URL источника трафика необходимо добавить уникальный ID учетной записи к указанному параметру в Postback URL источника.


Предположим, что значение параметра ID учетной записи равно 1234, поэтому, Postback URL источника трафика для 50onRed должен выглядеть следующим образом:

ДОСТУПНЫЕ URL-ТОКЕНЫ

PeerClick предлагает широкий спектр токенов для URL, которые позволяют вам передавать дополнительные данные обратно в источник после конверсии. Это позволяет вам ссылаться на данные, отправленные с PeerClick, с отчетами о конверсиях вашего источника.

Updated over 2 years ago

идентификаторов и URL-адресов и Интернета

В большинстве случаев событие генерируется, когда агент посещает веб-страницу и замечает ссылку между этой веб-страницей и частью зарегистрированного содержимого Crossref. Результатом является событие, где тема — это веб-страница, а объект — зарегистрированный контент. Мы используем «наилучший возможный» URL-адрес для ссылки как на Тему, так и на Объект.

Когда мы говорим «лучший» URL-адрес, мы пытаемся найти URL-адрес, который однозначно представляет контент. Это позволяет людям, использующим данные, находить События, соответствующие одному и тому же контенту. Если на определенный фрагмент контента ссылаются с использованием ряда разных URL-адресов, может быть сложно или невозможно найти события, которые на него ссылаются.

Вообще говоря, лучшим URL-адресом для части зарегистрированного контента (т. е. Объекта, такого как журнальная статья) является DOI. Лучший URL-адрес для веб-страницы (т. е. Тема, например, сообщение в блоге) — это ее канонический URL-адрес.

Канонические URL-адреса для субъектов

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

К веб-странице можно получить доступ через несколько различных URL-адресов. Чтобы взять реальный пример, следующие три URL-адреса соответствуют одному и тому же контенту:

  • https://arstechnica. com/?p=1177597
  • https://arstechnica.com/science/2017/09/new-evidence-would-push-life-back-to-at-least-3-95-billion-years-ago/
  • https://arstechnica.com/science/2017/09/new-evidence-would-push-life-back-to-at-least-3-95-billion-years-ago/?comments=1&post=34078349

Хотя важно записывать, где именно мы искали конкретную ссылку, также важно, чтобы мы представляли контент как можно более последовательно. На приведенной выше веб-странице есть метаданные, указывающие на канонический URL-адрес. Когда мы идентифицируем канонический URL-адрес, мы используем этот URL-адрес как

subj_id в событии. Мы сохраняем URL-адрес, который мы посетили, в subj.url , чтобы вы всегда знали, какой URL-адрес мы посетили в первую очередь.

Удаление URL отслеживания

Не все веб-страницы предоставляют канонические URL-адреса. Когда это происходит, мы используем следующий лучший URL-адрес, который мы посетили. Сначала мы применяем несколько шагов очистки:

Если URL-адрес, который мы посетили, привел к какому-либо перенаправлению (например, некоторые агрегаторы RSS включают свой собственный URL-адрес перенаправления), мы запишем конечный URL-адрес, к которому мы пришли. Это означает, что URL-адрес, по которому был записан контент, может отличаться от URL-адреса, который был посещен из ленты новостей. Пример:

  • URL найден в ленте новостей: http://feedproxy.google.com/~r/blogspot/wCeDd/~3/4ut6cGJY2FM/cshardware-inview-multi-pix-camera.html
  • URL-адрес назначения: http://nuit-blanche.blogspot.co.uk/2017/09/cshardware-inview-multi-pix-camera.html

Во-вторых, некоторые сервисы (например, в приведенном выше примере) применяют параметры URL отслеживания. Они не влияют на контент, но позволяют людям отслеживать, как передаются URL-адреса. Общие примеры включают utm_source , utm_medium , utm_campaign , которые используются Google Analytics. Наличие этих параметров URL-адреса может сбивать с толку, поскольку они означают, что один фрагмент контента может быть представлен бесконечным числом различных URL-адресов.

Чтобы противодействовать этому, мы удаляем известный набор параметров отслеживания из URL-адресов, прежде чем использовать их в поле subj_id . Вот пример:

  • URL, который мы посетили: http://nuit-blanche.blogspot.co.uk/2017/09/cshardware-inview-multi-pix-camera.html?utm_source=feedburner&utm_medium=feed&utm_campaign= Лента:+blogspot/wCeDd+(Nuit+Blanche)
  • URL-адрес, который мы используем для записи контента: http://nuit-blanche.blogspot.co.uk/2017/09/cshardware-inview-multi-pix-camera.html

Какой URL используется для

subj_id ?

При выборе subj_id мы используем следующие параметры по порядку:

  1. Канонический URL, указанный в метаданных HTML.
  2. В противном случае URL-адрес, по которому мы нашли контент (если были перенаправления, то конечный пункт назначения), с удаленными параметрами отслеживания.
  3. В противном случае (например, если были ошибки при удалении параметров отслеживания), URL-адрес, который посетил Агент.

DOI для объектов

В большинстве случаев объектом события является фрагмент содержимого, зарегистрированного в Crossref или DataCite. Для них лучшим URL-адресом для однозначной идентификации контента является DOI. Процесс сопоставления DOI также подтверждает, что это действительно часть зарегистрированного контента. Если мы не можем найти DOI, мы не можем подтвердить, что это контент, зарегистрированный Crossref, поэтому мы не создаем событие.

Мы ищем DOI, а также целевые страницы

Агенты данных событий ищут ссылки на зарегистрированные элементы контента, но люди в Интернете используют различные методы, чтобы найти их. Они могут использовать DOI с гиперссылкой (на которую можно щелкнуть) или DOI в виде простого текста (на которую нельзя щелкнуть). Они также могут использовать целевую страницу статьи (страница, на которую вы попадаете, когда нажимаете на DOI). Каждый источник отличается: мы склонны видеть, что большинство людей используют целевые страницы статей в социальных сетях и в сообщениях блогов, но в Википедии часто используются DOI.

Каждый агент будет пытаться сопоставлять зарегистрированные элементы контента как можно более широко, ища связанные и несвязанные DOI и URL-адреса целевых страниц статей. Мы поддерживаем список доменных имен, принадлежащих издателям (дополнительную информацию см. на странице артефактов), а также отслеживаем и запрашиваем эти домены. Когда мы видим URL-адрес, который может быть целевой страницей, мы пытаемся сопоставить его с DOI.

Соответствие целевой страницы не идеальное

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

Если кто-то обсуждает статью в блоге и использует ее DOI, и этот DOI существует, почти наверняка мы сопоставим ее и создадим событие. Если они обсуждают статью и используют URL ее целевой страницы, есть очень большая вероятность, что мы сопоставим ее, но процесс сопоставления не идеален.

Поэтому вам следует знать о разнице между Событиями, сопоставленными с использованием DOI, и событиями, сопоставленными с использованием URL-адреса целевой страницы, а также о том, что у нас может быть лучший коэффициент сопоставления для DOI.

Сопоставление также зависит от издателя. Для некоторых доменов целевых страниц мы можем легко сопоставить DOI. Для некоторых нам нужно сделать немного больше работы. Для других это невозможно.

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

Если вы издатель, ознакомьтесь с рекомендациями для издателей, чтобы убедиться, что у нас есть наилучшие шансы подобрать события для вашего контента.

Возможно, вам захочется узнать разницу

Когда мы сопоставляем Событие, потому что кто-то обсуждал Элемент, используя его DOI, единственная обработка, которая имеет место, — это нормализация DOI и проверка его существования. Вы можете увидеть весь процесс в протоколе свидетельских показаний для этого события, хотя в нем не так уж много.

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

Данные о событиях можно использовать по-разному. Возможно, вам будет интересно узнать:

  • Как часто люди используют DOI по сравнению с URL-адресами целевых страниц?
  • Меня интересуют только данные, в которых я могу быть на 100% уверен, что используется только DOI.
  • Я хочу знать об этих статьях. Меня не волнует, какой URL-адрес использовался для ссылки на них.

Когда событие ссылается на зарегистрированный элемент контента (почти все события делают это), оно будет использовать свой DOI как subj_id или obj_id . Соответствующие необязательные метаданные subj или obj могут содержать поле pid (которое всегда одинаково), но дополнительно оно может содержать поле url .

Если поле URL совпадает с полем PID (т. е. DOI), то вы знаете, что событие было собрано, потому что его DOI был упомянут. Если поле URL-адреса отличается (например, URL-адрес целевой страницы), вы знаете, что оно было собрано, поскольку был упомянут домен целевой страницы.

Всегда не один к одному

DOI можно присваивать книгам и главам книг, статьям и рисункам. Каждый агент будет выполнять свою работу максимально точно, с минимальной очисткой, которая может повлиять на интерпретацию.

Это означает, что если кто-то использует DOI для рисунка в статье в сообщении блога, мы запишем DOI этого рисунка. Если они используют URL-адрес целевой страницы для этой фигуры, мы сделаем все возможное, чтобы сопоставить ее с DOI. В зависимости от используемого метода и того, что сообщает нам целевая страница издателя, мы можем сопоставить DOI статьи или DOI рисунка.

Иногда две страницы могут претендовать на один и тот же DOI. Это может произойти, если издатель запускает два разных сайта с одинаковым содержанием. Также возможно, что у целевой страницы нет метаданных DOI, поэтому мы не можем сопоставить ее с событием.

Верно и обратное: иногда два DOI указывают на одну и ту же целевую страницу. Это может произойти случайно. Это редко, но случается. Это не оказывает существенного влияния на текущие методы сообщения о событиях.

Данные целевой страницы могут быть устаревшими

Мы периодически сканируем наши DOI, берем образцы и находим домены, используемые издателями. Это задокументировано в наших Артефактах, у которых есть версии и даты. Поэтому мы можем пропустить События в период между использованием нового домена и обновлением Артефакта.

Если издатель перестанет использовать домен целевой страницы статьи, мы не удалим его из списка. Агенты могут в любой момент вернуться и повторно обработать старые данные или работать с дампами исторических данных. Люди могут повторно использовать контент, который указывает на старые целевые страницы. Мы все еще хотим попытаться сопоставить их, если это возможно. Поэтому список доменов Artifact только растет. Как и в случае со всеми Артефактами, вы можете просмотреть все прошлые версии, чтобы увидеть, как они меняются с течением времени.

Мы не сопоставляем все домены

Некоторые DOI были зарегистрированы в таких доменах, как youtube.com . У нас нет возможности сопоставить видео на YouTube с DOI. Итак, мы исключаем это небольшое количество доменов, которые мы никогда не сможем сопоставить.

Мы не знаем всех URL-адресов целевых страниц, и невозможно обнаружить их все

Каждый DOI имеет URL-адрес ресурса, на который вы перенаправляетесь, когда вы нажимаете на гиперссылку DOI. Это известно Crossref и может быть получено из системы DOI. Однако в большинстве случаев это не конечный целевой URL. Многие издатели используют свои собственные внутренние службы ссылок и перенаправления, что означает, что когда вы нажимаете на DOI, вы перенаправляетесь через серию перенаправлений, прежде чем попасть на целевую целевую страницу статьи.

Возьмем простой пример DOI для демонстрации Crossref. DOI 10.5555/12345678 имеет URL-адрес ресурса http://psychoceramics.labs.crossref.org/10.5555-12345678.html , который вы можете увидеть в метаданных статьи. Если мы проследим за DOI, мы увидим только одно перенаправление, которое происходит по ссылке DOI.

URL-адрес Комментарий
https://doi.org/10.5555/12345678 Начальное перенаправление DOI со ссылки ресурса
http://psychoceramics.labs.crossref.org/10.5555-12345678.html Завершено

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

Возьмем другой пример, PLOS DOI 10.1371/journal.pone.0160106 . Ссылка на ресурс, которую вы можете увидеть в метаданных статьи, — http://dx.plos.org/10. 1371/journal.pone.0160106 , это внутренний преобразователь ссылок, управляемый PLOS.

Если мы перейдем по URL-адресу DOI, мы увидим следующую цепочку перенаправлений.

URL-адрес Комментарий
http://doi.org/10.1371/journal.pone.0160106 Начальное перенаправление DOI со ссылки ресурса
http://dx.plos.org/10.1371/journal.pone.0160106 Внутреннее перенаправление на сайте PLoS
http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0160106 Внутреннее перенаправление на сайте PLoS
http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0160106 Завершено

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

В некоторых случаях сайты издателей реализуют проверки, предотвращающие автоматический доступ, такие как запрос файлов cookie и выполнение перенаправлений с использованием JavaScript. В этом примере DOI анонимизирован, но основан на реальном примере. Попытка решить DOI 10.XXX/YYY.06.008 без включенных файлов cookie выдает:

URL Комментарий
http://doi.org/10.XXX/YYY.06.008 Начальное перенаправление DOI
http://FFF.AAA.com/retrieve/pii/DDD Внутреннее перенаправление
http://FFF.AAA.com/retrieve/articleSelectPrefsTemp?Redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&key=71835a2ddc744fbddf6d9а5а9003а4асед4б81а1 Внутреннее перенаправление
http://www.CCC.com/retrieve/pii/DDD Внутреннее перенаправление
https://secure. BBB.com/action/getSharedSiteSession?redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&rc=0&code=EEE Внутреннее перенаправление
https://secure.BBB.com/action/getSharedSiteSession?rc=1&redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&code=EEE Внутреннее перенаправление
https://secure.BBB.com/action/getSharedSiteSession?rc=2&redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&code=EEE Внутреннее перенаправление
https://secure.BBB.com/action/getSharedSiteSession?rc=3&redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&code=EEE Внутреннее перенаправление
https://secure.BBB.com/action/getSharedSiteSession?rc=4&redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&code=EEE Внутреннее перенаправление
https://secure.BBB.com/action/getSharedSiteSession?rc=5&redirect=http%3A%2F%2Fwww. CCC.com%2Fretrieve%2Fpii%2FDDD&code=EEE Внутреннее перенаправление
https://secure.BBB.com/action/getSharedSiteSession?rc=6&redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&code=EEE Внутреннее перенаправление
https://secure.BBB.com/action/getSharedSiteSession?rc=7&redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&code=EEE Внутреннее перенаправление
https://secure.BBB.com/action/getSharedSiteSession?rc=8&redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&code=EEE Внутреннее перенаправление
https://secure.BBB.com/action/getSharedSiteSession?rc=9&redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&code=EEE Внутреннее перенаправление
https://secure.BBB.com/action/getSharedSiteSession?rc=10&redirect=http%3A%2F%2Fwww.CCC.com%2Fretrieve%2Fpii%2FDDD&code=EEE Внутреннее перенаправление
http://secure. BBB.com/action/cookieAbsent Последняя страница ошибки

Последним шагом в этой цепочке является страница с ошибкой, в которой говорится, что файлы cookie необходимы, и поэтому невозможно разрешить DOI с помощью HTTP.

Правила членства в Crossref № 7 гласят:

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

Если издатели нарушат эти правила, мы сообщим им об этом.

Из-за таких ограничений, а также других практических ограничений мы не можем и не пытаемся посетить каждый DOI заранее, чтобы найти его целевую страницу.

Внешние стороны, сопоставляющие контент с DOI

Агенты перекрестных ссылок не единственные, кто создает События, и, следовательно, не единственные, кто создает сопоставления DOI с URL-адресами.

Внешняя сторона может хранить сведения об активности, связанной с Элементами, и использовать свои собственные системы для сопоставления Элементов с DOI, целевыми страницами и другими идентификаторами. Хотя их API можно запрашивать с помощью DOI, они могли зафиксировать действия в отношении элемента, используя URL-адрес его целевой страницы или другой идентификатор. Внутренние сопоставления между различными идентификаторами могут время от времени меняться, что может означать, что определенные действия могут быть зарегистрированы в отношении одного элемента в один момент времени, а затем в отношении другого элемента в другой момент времени. Таким образом, данные могут меняться со временем, и это может быть вызвано обновлением алгоритмов, а не действиями пользователя.

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

перезапись URL — Где добавить идентификатор в URL?

спросил

Изменено 3 месяца назад

Просмотрено 6к раз

Я использую удобные URL-адреса, например:

 http://localhost/gallery/photo/this-is-a-url-friendly-photo-caption

В удобный URL-адрес мне нужно добавить идентификатор фотографии, но, осмотревшись, я видел два способа добавления идентификатора в удобный URL-адрес, предварительно и после, например,

 http://localhost/ галерея/фото/это-это-удобная-ссылка-фото-подпись. 529

или

 http://localhost/gallery/photo/529/this-is-a-url-friendly-photo-caption

Есть ли преимущество в одну сторону? Или это просто вопрос предпочтений/личного вкуса?

  • url-rewriting
  • seo
  • url-design

Небольшое преимущество наличия ID в предпоследнем и slug в последнем сегменте пути ( /gallery/photo/529/this-is… ):

В некоторых контекстах URL-адрес может быть обрезан, например, разрывом строки в текстовых сообщениях электронной почты. Если ID приходит до (обычно длинного) слага, больше шансов, что идентификатор останется неповрежденным, а URL-адрес продолжит функционировать (при условии, что вы перенаправляете на канонический вариант с слагом).

Пример

Ваш вопрос в настоящее время имеет этот URL:

https://stackoverflow.com/questions/27343034/seo-friendly-url-where-to-add-the-id

При таком обрезании (=ID остается нетронутым) перенаправляет на канонический вариант и пользователь доволен:

https://stackoverflow.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *