【问题标题】:REST API endpoint - weird path parameterREST API 端点 - 奇怪的路径参数
【发布时间】:2014-04-12 22:04:37
【问题描述】:

我正在学习 REST API 和 URI 设计,我在这里找到了一个:

https://raw.githubusercontent.com/JeanVEGA/MI-MPR-DIP-Admission/master/examples/requests.sh

我有几个问题。

有例如:

User.resetPassword,由用户的 {email} 匿名

curl -i -X POST http://localhost:9090/admission/services/user/person/email:{email}/reset_password

我不懂建筑email:{email}...是什么意思?意思就是如果我有String path param,需要这样吗?

类似的在这里:

Term.get

curl -i -H "Accept: application/json" -H "X-CTU-FIT-Admission-Session: [session identifier from User.identity]" http://localhost:9090/admission/services/term/dateOfTerm:{dateOfTerm}/room:{room}

room:{room} - 这是因为房间应该是例如 123ABC 吗?所以不是数字所以需要这样写?

最后一个问题:

User.resetPassword for User by Admission Code,发送通知到用户的邮箱和这个{email}

curl -i -H "X-CTU-FIT-Admission-Session: [session identifier from User.identity]" -X POST http://localhost:9090/admission/services/user/admission/{admissionCode}/person/email:{email}/reset_password

我的问题是“reset_password”...我认为由于正确的设计原则,任何动词都不应该在 URI 中...因为如果动词在 URI 中,我认为这意味着资源实际上是一个操作。

【问题讨论】:

    标签: http rest curl state


    【解决方案1】:

    该 url 只能是资源标识符。所以这是一个url template,它等待一个唯一的电子邮件地址作为参数。一个填写好的模板应该是这样的:

    ./person/email:my@email.adr/reset_password
    

    注意:

    reset_password 不是有效的 REST 资源(它描述的是服务而非资源),POST 方法是 mostly for resource creation(不适用于更新或部分更新)。真正的 REST 请求如下所示:

    PUT ./person/email:{email}/password "newpass"
    PUT ./person/{id}/password "newpass"
    PUT ./person/email:{email}/identification_factors/password "newpass"
    PATCH ./person/email:{email}/identification_factors {password: "newpass"}
    

    等等……

    【讨论】:

    • 我可以询问我的用例吗?我有一个系统可以管理集合中少数算法的演变。我以这种方式设计了我的端点: 为了检测集合中的哪个算法是最好的:/collection/{collection-id}/tasks/best (GET) 更新选择了一些算法:/collection/{collection-id}/ tasks/selection/algorithms/{algorithm-id} 并向算法发送反馈:/collection/{collection-id}/tasks/feedback/algorithms/{algorithm-id} 这是正确的设计吗?或者没有有效的 REST 资源? (我的意思是“最佳”、“选择”、“反馈”?)
    • 我认为最好将 mapreduce 部分放入 queryString 中(唯一 ID 除外)。所以/collection/{collection-id}/tasks?best=true/collection/{collection-id}/tasks?filter="best:true" 等...我不确定其他人...通过a:b = 1:n 关系:/a/bs/{b-id},通过a:b = 1:1 关系:/a/b,通过a:b = n:m 关系:@ 987654334@、/b/{b-id}/ab/{ab-id}/a/ab/{ab-id}/b 是有效的 url。其他任何东西,比如哪个是最好的,哪个早于时间戳,......应该去 queryString 因为它是关于当前查询的,而不是关于资源结构的。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-11
    相关资源
    最近更新 更多