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

Ответ 1

Вы всегда можете просто принимать пробелы:-) (querystring escaped as %20)

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

Ответ 2

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

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

Я бы сделал

/personNamed/Joe+Blow

Ответ 3

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

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

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

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

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

И для поиска вы можете использовать URL-адреса, не принадлежащие RESTful:

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

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

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

Ответ 4

Для поиска:

/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} не успокаивается. Он не называет ресурсы и не называет их лаконично.

Ответ 5

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

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

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

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