Выбор PUT/POST в REST для создания нескольких ресурсов

Question

Я знаю хорошо известный вопрос здесь: PUT vs POST in REST

Однако я немного запутался в одном моем случае и хотел бы обратиться за советом, чтобы правильно дизайн моего RESTful WS:

Предположим, моя система работает так:

Моя система будет иметь несколько рабочих мест партии определены (например, JOB1, JOB2).

За каждый день, я буду просить мою систему, чтобы создать список пакетного графика работы, предоставляя определенную дату (например, я прошел в 2014-12-25, то система будет создавать JOB1(2014-12-25) и JOB2(2014-12-25).

Пользователь может инициировать график пакетного задания для выполнения

Я хочу обратиться за советом к собственно выставить их в качестве ресурса:.

Должен ли я сделать POST или PUT на ресурс /batchSchedules, чтобы вызвать создание batchSchedules для конкретная дата? Как должен выглядеть URL-адрес e это правильный RESTful API?

Как выглядит «запуск расписания»?

Я имею в виду эти два варианта, но оба не звучит совсем правильно меня:

---

Подход 1:

Чтобы создать расписание на конкретную дату: PUT к /batchSchedules/2014-12-25 с пустым тело запроса, поскольку кажется, что я создаю «кучу расписаний» в качестве ресурсов, объявленных в URL.(Тем не менее, это кажется правильным, потому что я не собираюсь его заменять, если я его снова назову, что выглядит не очень хорошо)

Чтобы запустить выполнение расписания: PUT - /batchSchedules/2014-12-25/JOB1, поскольку он, кажется, заменяет ресурсы пакетного расписания (но это выглядит странно сог я на самом деле не заменить ресурс, не может занять пост здесь, потому что я на самом деле не генерируя ребенок ресурсов ниже URL)

Чтобы получить статус с графиком значимого вклада: GET/batchSchedules/2014-12-25/JOB1

Получить расписание: GET/batchSchedules?id=12345 который 12345 это идентификатор для расписания

---

Подход 2: Чтобы создать расписание на конкретную дату: POST к /batchSchedules с датой в теле запроса, как это кажется, что я создаю дочерний ресурс пакетных расписаний

Чтобы запустить выполнение расписания: PUT - /batchSchedules/2014-12-25/JOB1, поскольку он, кажется, заменяет ресурсы расписания (но выглядит странно, потому что я действительно не заменяю ресурс, не могу взять POST здесь, потому что я фактически не генерирую дочерние ресурсы ниже URL-адреса)

Чтобы получить статус с графиком значимого вклада: GET/batchSchedules/2014-12-25/JOB1

Чтобы получить статус расписания: GET/batchSchedules?id=12345 который 12345. является идентификатором для расписания

---

Подход 3:

Получить статус расписания со значимым вводом: GET/batchSchedules?job=JOB1&date=2014-12-25

Чтобы получить статус расписания:/batchSchedules/12345 который +12345 это идентификатор для расписания

Чтобы создать расписание на конкретную дату: POST к /batchSchedules с датой в теле запроса, как это кажется, что я создаю кучу детских ресурсов пакетных графиков по /batchSchedules (Безразлично «т, кажется, довольно хорошо)

чтобы запустить график выполнения: PUT или POST к /batchSchedules?job=JOB1&date=2014-12-25, как это кажется заменой партии график ресурсов (выглядит очень странно для меня)

---

Какой из них является подходящим способом подвергнуть мой WS надлежащему методу REST?

Answer 1

Если я правильно читаю ваш вопрос, клиент не предоставляет никакой информации, кроме даты создания графика. Если это правда, я буду спорить, что вы должны использовать GET, а не PUT или POST. Понятно, что для клиента нет никакой причины сделать что-либо для создания ресурса - все это на стороне сервера. Весь клиент знает, что «я хочу расписание пакетного задания для дня X». Независимо от того, нужен ли сервер для создания нового расписания или извлечения существующего расписания, это не то, о чем должен заботиться клиент.

GET /batchSchedules?date=2014-12-25 
{ 
    "id": 12345, 
    "self": "/batchSchedules/12345", 
    "jobs": [{ 
      "id": 67890, 
      ... 
     }, 
     ... 
    ] 
} 

POST /scheduledExecutions 
{ 
    "scheduleId": 12345, 
    "date": "2014-12-25" 
} 

Ответ от должности будет либо быть 200 OK, если партия будет сделана немедленно, или скорее 202 Accepted, наряду с Location заголовком запроса для URI для результатов пакетных, что-то вроде /scheduledExecutions/67890. Вызов GET на этом URI будет возвращать информацию о состоянии в пакетной версии, возможно, включая URI для статусов различных заданий в пакете.

GET /scheduledExecutions/67890 
{ 
    "status": "In progress", 
    "date": "2014-12-25", 
    "jobs": [{ 
     "id": 13579, 
     "status": "Complete", 
     "self": "/scheduledJobs/13579" 
    }, 
    { 
     "id": 24680, 
     "status": "In progress", 
     "self": "/scheduledJobs/24680" 
    } 
} 

Если я неправильно понял, и вы выполнения заданий, а не целые графики, то вы бы POST /scheduledJobs и GET /scheduledJobs вместо /scheduledExecutions.