Что использовать для пробела в REST URI? - PullRequest
Новая
       21

Что использовать для пробела в REST URI?

14 голосов
/ 09 апреля 2010

Что я должен использовать:

  • / findby / имя / {первой} _ {последний}
  • / findby / имя / {первой} - {последний}
  • / findby / имя / {первой}; {последний}
  • / findby / имя / первый / {первый} / последний / {} Последнее

и т.д.

URI представляет ресурс Person с 1 именем, но мне нужно логически отделить первое от последнего, чтобы идентифицировать каждое. Мне нравится последний пример, потому что я могу сделать:

  • / findby / имя / первый / {первой}
  • / findby / имя / фамилия / {последний}

Ответы [ 5 ]

13 голосов
/ 17 февраля 2014

Почему бы не использовать + для пробела?

Я в недоумении: тире, минусы, подчеркивания,% 20 ... почему бы просто не использовать +? Так обычно пробелы кодируются в параметрах запроса. Да, вы тоже можете использовать% 20, но почему, выглядит ужасно.

Я бы сделал 

/personNamed/Joe+Blow
13 голосов
/ 09 апреля 2010

Вы всегда можете просто принять пробелы :-) (строка запроса экранирована как% 20)

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

2 голосов
/ 10 апреля 2010

Для поиска: 

/people/search?first={first}&last={last}
/people/search?first=george&last=washington

Для путей к ресурсам: 

/people/{id}-{first}-{last}
/people/35-george-washington

Если вы используете Ruby on Rails v3 в стандартной конфигурации, вот как вы можете это сделать. 

# set up the /people/{param} piece
# config/routes.rb
My::Application.routes.draw do
  resources :people
end

# set up that {param} should be {id}-{first}-{last}
# app/models/person.rb
class Person < ActiveRecord::Base
  def to_param
    "#{id}-#{to_slug(first_name)}-#{to_slug(last_name)}"
  end
end

Обратите внимание, что ваше предложение /findby/name/first/{first}/last/{last} не является успокоительным. Он не называет ресурсы и не называет их кратко.

2 голосов
/ 10 апреля 2010

Мне нравится использовать "_", потому что это символ, наиболее похожий на пробел, который делает URL читаемым.

Однако предоставленные вами URL не выглядят действительно РЕСТАЛЬНЫМИ. URL должен представлять ресурс, но в вашем случае он представляет поисковый запрос. Поэтому я бы сделал что-то вроде этого: 

/people/{first}_{last}
/people/{first}_{last}_(2)  - in case there are duplicate names

В этом случае вам необходимо сохранить слаг ({first}_{last}, {first}_{last}_(2)) для каждой пользовательской записи. Еще один способ добавить идентификатор, так что вам не придется беспокоиться о слизняках: 

/people/{id}-{first}_{last}

А для поиска вы можете использовать не RESTful URL: 

/people/search?last={last}&first={first}

Они будут отображать список результатов поиска, в то время как URL-адреса над страницей для конкретного человека.

Я не думаю, что есть смысл делать поисковые URL RESTful, пользователи, скорее всего, захотят делиться ссылками на страницу определенного человека, а не на страницы результатов поиска. Что касается поисковых систем, избегайте использования одного и того же контента для нескольких URL, и вам даже следует запретить индексирование страниц результатов поиска в файле robots.txt

.
0 голосов
/ 15 июня 2014

Самый сложный выбор должен всегда и в первую очередь учитывать два ограничения:

  1. Поскольку вы никогда не узнаете, насколько опытным разработчик или устройство, которое внедряется, имеет дело с обработкой urlendoding, я всегда буду пытаться ограничиться таблицей безопасных символов , как показано в отличном rant (пожалуйста) Прекратить использование небезопасных символов в URL-адресах
  2. Также - мы хотим рассмотреть клиента, использующего API. Можем ли мы иметь всю структуру, легко представляемую и доступную на языке программирования на стороне клиента? С какими спецсимволами этот запрос оставляет нас? То есть $ будет хорошо в именах переменных javascript и, таким образом, будет непосредственно доступен в разобранном результате, но клиенту PHP все равно придется использовать более сложную (и потенциально более запутанную) нотацию $userResult->{'$mostVisited'}->someProperty ... что выстрел в вашем собственная нога! Таким образом, для этих двух (и нескольких других сред программирования) подчеркивание кажется единственным допустимым вариантом.

В противном случае я в основном согласен с ответом @ yfeldblum - я бы отличал конечную точку поиска от фактического поиска уникальных ресурсов. Мне кажется больше REST, но что более важно, у этих двух есть значительная разница в стоимости на вашем сервере API - таким образом вы можете легче различать и, например, взимать более высокую стоимость или ограничивать скорость поиска конечной точки - если вы когда-либо нужно это.

To быть прагматичным , в отличие от "RESTafarian", упомянутый подход /people/35-george-washington может (и должен imho) в основном отвечать только на id, поэтому, если вы хотите именованный, urlsafe-for-for- ссылка-пустышка, перечислите ссылку как /people/35_george_washington. Другими идеями могут быть /people/35/#GeorgeWashington (таким образом, ломая тонны RFC) или /people/35_GeorgeWashington - API не волнует.

...