【问题标题】:Naming conventions for a few operations (verbs) in RESTREST 中一些操作(动词)的命名约定
【发布时间】:2016-09-23 15:08:32
【问题描述】:

我在设计 REST api 时尝试不使用动词,但努力将操作重新想象为资源(如在 REST 中)

这里有一些

/guest/accountnumber/isValid/{username} (returns a Boolean by checking if account number is valid)
/user/associateAccount/{firstAcc}/{secondAcc} (returns a Boolean. Links up the two passed in accounts)

我真的不想故意遵循一个不好的做法并扼杀 REST 的精神,但我正在努力重新将其视为资源状态传输,而不是禽类 XML RPC 样式操作或远程方法调用。任何帮助表示赞赏!

【问题讨论】:

    标签: java web-services api rest naming-conventions


    【解决方案1】:

    布尔值是否表示操作成功?可以使用 HTTP 响应代码。

    对于“关联帐户”,将 关联 本身想象为一个对象。可以将这些对象想象为位于它们所指帐户下的“文件夹”中。

    您可以让 PUT /accounts/{firstAcc}/associations/{secondAcc} 返回一个 HTTP 代码,指示帐户是否已成功关联(例如 201 Created409 Conflict)。 DELETE /accounts/{firstAcc}/associations/{secondAcc} 可用于删除链接。

    对于您的另一个示例,我看不出您要表达的确切内容。是否只是检查帐户是否存在?为此,我会使用HEAD /accounts/{number}。如果帐户有效则返回200,否则返回404

    【讨论】:

    • 很好的答案。但是,我要补充一点,通常避免动词的关键是将动作和属性想象为对象。我见过的最好的例子:而不是 POST(或 PUT)到 /rocket/launch 使用 PUT(或 POST)到 /rocket/launches/ 来“创建火箭的新发射对象属性”。在更一般的 isValid 检查现有对象的情况下,您可以尝试获取有效性属性(GET /accounts/{id}/validity )或将其用作从 GET /accounts/{id} 返回的对象的属性
    猜你喜欢
    • 2015-12-15
    • 2010-10-31
    • 2010-09-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多