Из Википедии: унифицированный указатель ресурса
Путь , который содержит данные, обычно организованные в иерархической форме , которые отображаются в виде последовательности сегментов, разделенных косыми чертами.
Необязательный запрос , отделенный от предыдущей части знаком вопроса (?), Содержащий строку запроса неиерархических данных .
- В соответствии с концептуальным дизайном URL-адреса, мы могли бы реализовать PathParam для иерархических компонентов данных / директив / локаторов или реализовать QueryParam, когда данные не являются иерархическими. Это имеет смысл, поскольку пути естественным образом упорядочены, тогда как запросы содержат переменные, которые могут быть упорядочены произвольно (неупорядоченные пары переменная / значение).
Предыдущий комментатор написал:
Я думаю, что если параметр определяет конкретную сущность, вы должны использовать переменную пути.
Другой написал,
Используйте @PathParam для поиска по идентификатору. Пользователь @QueryParam для фильтра или если у вас есть фиксированный список опций, которые пользователь может передать.
Другой,
Я бы порекомендовал поместить в путь все обязательные параметры, а любые необязательные параметры должны быть параметрами строки запроса.
- Тем не менее, можно реализовать гибкую неиерархическую систему для идентификации конкретных объектов! Можно иметь несколько уникальных индексов в таблице SQL и позволить идентифицировать сущности, используя любую комбинацию полей, которые составляют уникальный индекс! Различные комбинации (возможно, также упорядоченные по-разному) могут использоваться для ссылок от различных связанных объектов (источников). В этом случае мы могли бы иметь дело с неиерархическими данными, используемыми для идентификации отдельных объектов - или в других случаях, могли бы указывать только определенные переменные / поля - определенные компоненты уникальных индексов - и извлекать список / набор записей. В таких случаях может быть проще, логичнее и разумнее реализовать URL-адреса как QueryParams!
Может ли длинная шестнадцатеричная строка разбавить / уменьшить значение ключевых слов в остальной части пути? Возможно, стоит подумать о возможных последствиях SEO размещения переменных / значений в пути или в запросе.и последствия для человеческого интерфейса того, хотим ли мы, чтобы пользователи могли просматривать / исследовать иерархию URL-адресов, редактируя содержимое адресной строки. Моя страница 404 Not Found использует переменные SSI для автоматического перенаправления неработающих URL-адресов их родителям! Поисковые роботы также могут пересекать иерархию путей. С другой стороны, лично, когда я делюсь URL-адресами в социальных сетях, я вручную удаляю любые частные уникальные идентификаторы - обычно путем обрезания запроса по URL-адресу, оставляя только путь: в этом случае есть некоторая утилита для размещения уникальных идентификаторов. в пути, а не в запросе. Хотим ли мы упростить использование компонентов пути в качестве грубого пользовательского интерфейса, возможно, зависит от того, являются ли данные / компоненты удобочитаемыми или нет. Вопрос читабельности относится к вопросу об иерархии: часто данные, которые могут быть выражены как удобочитаемые ключевые слова, также являются иерархическими; в то время как иерархические данные часто могут быть выражены как удобочитаемые ключевые слова. (Сами поисковые системы могут быть определены как расширение использования URL-адресов в качестве пользовательского интерфейса.) Иерархии ключевых слов или директив могут быть не строго упорядочены, но обычно они достаточно близки, чтобы мы могли охватить альтернативные случаи в пути, ипометьте один вариант как «канонический» случай .
Есть несколько принципиальных вопросов, на которые мы можем ответить с помощью URL для каждого запроса:
- Какую запись / вещь мы запрашиваем / обслуживаем?
- Какие из нас интересуют?
- Как мы хотим представить информацию / записи?
Q1 почти наверняка лучше всего охватывается путем или PathParams. Q3 (который, вероятно, контролируется набором произвольно упорядоченных необязательных параметров и значений по умолчанию); почти наверняка лучше всего покрывается QueryParams. Q2: это зависит ...