2014-03-31 49 views
0

我知道一个众所周知的问题在这里:PUT vs POST in REST选择在REST创建多个资源

不过我有点在我的情况的一个困惑,希望寻求提醒正确设计我的REST风格的WS:

假设我的系统的工作是这样的:

我的系统定义了多个批处理作业(如JOB1JOB2)。

每一天,我会要求我的系统创建批处理作业计划的列表,通过提供特定日期(例如,我通过了情节中字,则系统会JOB1(2014-12-25)JOB2(2014-12-25)

用户可以触发一个批处理作业计划执行

我想寻求提醒适当的揭露这些为资源:

我应该做一个POST或PUT到资源/batchSchedules触发了创作的batchSchedules具体的日期?URL应该如何看起来像mak它是一个适当的RESTful API?

“计划触发”应该是什么样子?

我想这两种选择的,但两者并不听起来很正确的对我说:


方法1:

要为特定日期创建时间表:PUT/batchSchedules/2014-12-25空请求正文,因为我似乎正在创建“一堆日程表”作为在URL中声明的资源。(然而,它似乎是对的,因为如果我再次调用它,看起来不太好,我不打算替换它)

要触发计划执行:PUT/batchSchedules/2014-12-25/JOB1,因为它似乎取代了批处理计划资源GET/batchSchedules/2014-12-25/JOB1

要获得计划的状态与有意义的输入(但它看起来很奇怪怎么我我没有真正更换的资源,不能因为我其实不是生成URL以下的儿童的资源在这里乘坐POST)

要获得计划的状态:GET/batchSchedules?id=12345其中12345是一个时间表


方法2 ID: 要创建一个特定的日期安排:POST/batchSchedules带日期的请求主体,因为它似乎是我创建批处理调度的子资源

要触发一个时间表执行:PUT/batchSchedules/2014-12-25/JOB1,因为它似乎取代了批处理调度资源(但它看起来很奇怪,因为我实际上并不真正替换资源,因为我实际上并没有在URL下面生成一个子资源)

要使用有意义输入得到一个时间表的状态:GET/batchSchedules/2014-12-25/JOB1

为了得到一个时间表的状态:GET/batchSchedules?id=12345这12345为时间表ID


方法3:

要获得具有有意义输入的时间表状态:GET/batchSchedules?job=JOB1&date=2014-12-25

要获得时间表的状态:GET/batchSchedules/12345其中12345是一个时间表

要为特定日期创建时间表ID:POST/batchSchedules带日期的请求主体,因为它似乎是我创造/batchSchedules下一堆批处理调度的子资源(没有按“T似乎相当不错)

要触发计划执行:PUTPOST/batchSchedules?job=JOB1&date=2014-12-25,因为它似乎取代了一批资源调度(看起来真的很奇怪,我)


其中哪些是以适当的REST方式公开我的WS的适当方式?

回答

0

如果我正在阅读您的问题,客户除了提供日期以外的任何信息来构建计划。如果这是真的,我会争辩说你应该使用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。在该URI上调用GET将返回批处理的状态信息,可能包括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 /scheduledJobsGET /scheduledJobs,而不是/scheduledExecutions

+0

感谢您的回复,我会尽力进一步阅读。只是一件事:我想避免使用GET来创建这些“日程安排”,因为我希望创建是明确的,并且GET/schedule/DATE应该为我提供特定日期的日程安排(即以前创建的日程安排)。如果这是我的设计决策,我应该如何以REST方式公开它?我相信我对工作时间表的想法更像是你的“时间表执行”:我的“时间表”是一项计划在特定日期执行的工作。 –

+0

那么,如果你决定使用PUT/POST,那么它就是客户所拥有的信息。如果客户可以*完全*指定时间表,那么PUT是适当的。如果有什么信息可以改变客户端没有的信息,你*必须*使用POST。 –