Есть ли лучший успокаивающий интерфейс для этого?

GET https://api.website.com/v1/project/employee;company-id={company-id}, 
title={title-id}?non-smoker={true|false}&<name1>=<value1>&<name2>=<value2>&<name3>=<value3>

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

Есть ли лучший способ определить интерфейс?

Этот API не должен создавать объект-сотрудник. Он предназначен для получения массива объектов-сотрудников, принадлежащих конкретной компании, и имеет определенный заголовок и другие критерии фильтра.

источник

2013-02-22 Vink

Я не знаю, есть ли лучший способ, потому что это зависит часто от используемой вами технологии и ее идиом.

Однако здесь два различных URI конструкции, которые мне нравятся (и почему)

#1 GET https://api.website.com/v1/project/employee/{company-id}?title={title-id}&non-smoker={true|false}&<name1>=<value1>&<name2>=<value2>&<name3>=<value3> 

#2 GET https://api.website.com/v1/project/company/{company-id}/employee?title={title-id}&non-smoker={true|false}&<name1>=<value1>&<name2>=<value2>&<name3>=<value3>

Как вы можете видеть, как в примере я извлеченного компания-идентификатор из строки запроса . Я предпочитаю добавлять обязательные параметры в поле информации , чтобы отличить их. Затем во втором URI ресурс сотрудника вложен в компанию. Таким образом, вы можете легко догадаться, что вы можете получить всех сотрудников из определенной компании, что не очевидно в первом примере.

источник

2013-02-22 11:32:30 basgys

Я вроде как второй здесь. Но если название было также ** обязательным **, вы добавили бы его в ** информацию о пути **. Это не звучит хорошо для меня. – Vink

Извините за задержку, но вы абсолютно правы, это тоже нехорошо. На самом деле я не могу найти правило, которое может применяться ко всем случаям, но такие параметры, как PK или FK (например, идентификатор компании), являются хорошими кандидатами для этого. – basgys

Вы создаете новый объект сотрудника? Если это так, более подходящим является POST (создание). Хорошей подсказкой являются все данные, которые вы нажимаете на URL. Все, что должно быть в теле объекта POST.

источник

2013-02-22 02:05:58

@Vink: Если это было вашим намерением, я второй ответ. REST - это многого для понимания того, что означает «безопасный» и «идемпотентный» в спецификации HTTP. Таким образом, создание объекта с помощью GET абсолютно БЕСПЛАТНО. POST или PUT (который является идемпотентным) - это путь. –

@ Aurélien, Mea Culpa! Я не был ясен. Предполагается, что этот api должен получить объекты-сотрудники, которые удовлетворяют заданным критериям принадлежности к определенной компании, имеющие конкретное название работы и некоторые другие критерии фильтрации. – Vink

Этот api должен предоставлять объекты-сотрудники, удовлетворяющие заданным критериям принадлежности к определенной компании, имеющие конкретное название работы и некоторые другие критерии фильтрации.

Лично я бы просто создал ваш URI как http://acme.com/employee/?company=X&title=Y&non-smoker=Z&T=U. Я бы не писал «в камне», что компания обязательна: ваш API будет легче изменить.

Однако вы должны учитывать, что несколько «больших» запросов намного быстрее, чем множество мелких. Более того, представления URI могут быть эффективно кэшированы. Поэтому часто лучше иметь URI на основе идентификаторов (поскольку есть больше шансов, что их снова попросят). Итак, вы можете получить полный список сотрудников компании (плюс другие данные о самой компании) с http://acme.com/company/X, а затем отфильтровать его на стороне клиента.

источник

2013-02-22 09:24:17

Есть ли лучший успокаивающий интерфейс для этого?

ответ

Смежные вопросы