REST дизайн URL

Question

Давайте у вас есть URL, как это:

POST /departments, который создает новый департамент
и POST /employees, который создает новый трудоустроить.

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

Предположим, что работник может принадлежать нескольким отделам.

Как бы вы структурировали соответствующий URL-адрес и, самое главное, вы использовали POST или PUT для выполнения этой операции? Например: добавить Билла отдела книг, вы бы использовать:

POST /departments/Books/employees/Bill

Или:

PUT /departments/Books 
{ 
    "employee" : "Bill" 
} 

Прежние смотрит на меня более семантически правильно, так как в любом случае в POST теле я имеют больше данных, которые характеризуют это новое отношение. Кроме того

GET /employee/Bill возвращает тело, которое отличается от возвращаемой:
GET /departments/Books/employees/Bill

Так мне добавлять отношения, как создать новые ресурсы. Однако мне не нравится тот факт, что в
POST /departments/Books/employees/Bill Я явно указываю новый ресурс в URL.

Answer 1

Предполагая, что вы знаете имя сотрудника, прежде чем стороны, кажется, самый простой способ сделать это состоит в использовании PUT

PUT /departments/books/employees/bill 

Если ресурс «Билл» является совершенно новым, то возвращает 201. Если «Билл» уже существует, то вернуться 200.

GET /departments/books/employees/bill 

и

GET /dapartments/giftcards/employees/bill 

и

GET /employees/bill 

должен вернуть те же данные. Я не уверен, почему бы и нет, если «Билл» будет одним и тем же ресурсом в обоих случаях.

Answer 2

Не имеет значения, как выглядит ваш URI, системы на основе REST не заботятся.

GET {someUrlToDept} 
=> 
200 OK 
Content-Type: application/hal+xml 

<resource> 
    <DepartmentName>Books</DepartmentName> 
    <links> 
     <link rel="http://myapi.com/rels/employees" href="{someUrlToEmployeesForThisDept}"/> 
    </links> 
<resource> 

POST {someUrlToEmployeesForThisDept} 
Content-Type : application/hal+xml 

<resource> 
    <EmployeeName>Bill</EmployeeName> 
    <OtherStuff>...</OtherStuff> 
</resource> 

Answer 3

На ваш вопрос нет однозначного ответа. Связь между A и B, когда у вас есть URI, содержащий «A/B», предоставляется разработчику (AFAIK).

Однако, я думаю, что URI должны следовать принципу наименьшего удивления и поэтому иметь ограниченное количество значений.

Для меня, А/В может представлять только три возможных отношений:

1. «Б является экземпляром концепции А»;
2. "B - понятие, которое составляет часть экземпляр A";
3. «A - это понятие, B - понятие, а B - своего рода A».

Ваш вопрос касается использования корпуса 2. Я предпочитаю, чтобы случай 2 использовался только для отношения «является частью».

Если я применить эту логику к ответить на ваш вопрос, делает работник часть особый отдел?

Конечно нет, потому что вы написали, что сотрудник может работать для нескольких отделов. Отношения между «сотрудником» и «отделом» являются отношениями «работает для», это ассоциация, а не композиция. По этой причине я не стал бы выступать за использование:

/departments/Books/employees/Bill 

Я думаю явную ссылку внутри:

/departments/Books 

Ressource, указывая на:

/employees/Bill 

Ressource мог быть более ясными и менее склонными к неправильным толкованиям в долгосрочной перспективе.