В RESTful API, как правильно использовать разделенные косой чертой и параметры строки запроса? - PullRequest
Новая
       13

В RESTful API, как правильно использовать разделенные косой чертой и параметры строки запроса?

2 голосов
/ 05 декабря 2011

Например, какой из них (если есть) наиболее RESTful?Почему ?? 

/employees/id/45
/employees/?id=45
/employees/45

Спасибо!

Ответы [ 3 ]

3 голосов
/ 05 декабря 2011

Если вы почти всегда будете получать сотрудников на основе идентификатора, я бы просто использовал 

/employees/45

Планируете ли вы поддерживать поиск сотрудников на основе нескольких свойств? Если это так, перейдите с: 

/employees/id/45

Так как вы можете добавить 

/employees/dob/19940604

Действительно, я думаю, вы хотели бы иметь: 

/employee/45

Который всегда возвращает один экземпляр сотрудника (обратите внимание, что сотрудник является единственным), а затем некоторый URL, который возвращает EmployeeCollection, на основе критериев: 

/employees/dob/19940604
/employees/lastname/crumbling
1 голос
/ 05 декабря 2011

Для сотрудников типа REST API обращаются напрямую. Подразумевается, что сущность однозначно идентифицируется с помощью id. следовательно, наиболее подходящим URL является

/employees/45

Хотя другой вариант
/employees/?id=45
одинаково действителен

Основной аспект заключается в том, что GET / PUT / POST должен использоваться соответствующим образом для того же URL для соответствующего API.

0 голосов
/ 05 декабря 2012

Правильный ответ на ваш вопрос, который (если таковой имеется) является наиболее RESTful, состоит в том, что все они одинаково RESTful. Это потому, что URI непрозрачны для клиента REST вследствие HATEOAS, хотя они должны быть "взломаны" для читателя. Когда вы щелкаете ссылку в веб-браузере, URI (или, по крайней мере, должен быть) скрыт за каким-то более значимым (семантическим) текстом, например, ранее в этом параграфе. Для вас как для сайта не имеет значения, какой адрес находится в адресной строке, если только вы не хотите начинать исследовать, отсекая биты от URI или добавляя / заменяя свои собственные термины.

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

...