【问题标题】:Choice of PUT/POST in REST for creating multiple resources在 REST 中选择 PUT/POST 以创建多个资源
【发布时间】:2014-03-31 10:38:20
【问题描述】:

我知道这里有一个众所周知的问题:PUT vs POST in REST

但是我对我的一个案例有点困惑,想寻求建议以正确设计我的 RESTful WS:

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

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

对于每一天,我都会要求我的系统创建一个批处理作业计划列表,通过提供一个特定的日期(例如,我在 2014-12-25 通过,那么系统将创建JOB1(2014-12-25)JOB2(2014-12-25)

用户可以触发批处理作业计划来执行。

我想寻求建议以正确地将这些公开为资源:

我应该对资源 /batchSchedules 执行 POST 还是 PUT 以触发在特定日期创建 batchSchedules? URL 应该如何使其成为适当的 RESTful API?

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

我正在考虑这两种选择,但我觉得这两种选择都不对:


方法一:

要为特定日期创建计划:PUT/batchSchedules/2014-12-25,请求正文为空,因为我似乎正在创建“一组计划”作为 URL 中声明的资源。 (但是,它似乎是正确的,因为如果我再次调用它,我不会替换它,这看起来不太好)

要触发计划执行:PUT/batchSchedules/2014-12-25/JOB1,因为它似乎替换了批处理计划资源(但它看起来很奇怪,因为我并没有真正替换资源,不能在这里进行 POST,因为我实际上没有生成URL 下的子资源)

要通过有意义的输入获取计划的状态:GET/batchSchedules/2014-12-25/JOB1

要获取计划的状态:GET /batchSchedules?id=12345 其中 12345 是计划的 ID


方法 2: 要为特定日期创建计划:POST/batchSchedules,请求正文中带有日期,因为我似乎正在创建批处理计划的子资源

要触发计划执行:PUT/batchSchedules/2014-12-25/JOB1,因为它似乎替换了批处理计划资源(但看起来很奇怪,因为我并没有真正替换资源,不能在这里进行 POST,因为我实际上没有生成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 下创建了一堆批处理计划的子资源(似乎不太好)

要触发计划执行:PUTPOST/batchSchedules?job=JOB1&date=2014-12-25,因为它似乎替换了批处理计划资源(对我来说看起来很奇怪)


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

【问题讨论】:

    标签: rest


    【解决方案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,以及批处理结果URI 的Location 请求标头,例如/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

    【讨论】:

    • 感谢您的回复,我会尝试进一步阅读。只有一件事:我想避免在创建那些“时间表”时使用 GET,因为我希望创建是明确的,并且 GET /schedules/DATE 应该给我一个特定日期的时间表(即先前创建的)。如果这是我的设计决定,我应该如何以 RESTful 方式公开它?而且我相信我对工作计划的看法更像是您的“计划执行”:我的“计划”是计划在特定日期执行的工作。
    • 好吧,如果你决定使用 PUT/POST,它归结为客户端所拥有的信息。如果客户端可以完全指定调度,那么 PUT 是合适的。如果有任何信息可以更改而客户端没有,您必须使用 POST。
    猜你喜欢
    • 2017-12-26
    • 2011-01-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-04-04
    • 1970-01-01
    • 2020-06-07
    相关资源
    最近更新 更多