首页 > 解决方案 > 计算器应用程序的统一界面

问题描述

我正在为基本计算器设计其余的 api。

我需要知道定义接口的最佳实践是什么?

/calc-service/add
/calc-service/sub
/cal-service/mul

第二种方法

/calc-service/?params

标签: djangorestapidjango-rest-framework

解决方案


我需要知道定义接口的最佳实践是什么?

REST 不关心您对资源标识符使用什么拼写。

大多数计算查询都是安全的,也就是说“只读”,因此您通常计划对请求使用GET语义,这反过来意味着所有客户端提供的操作数都将出现在 target-uri

/calc-service/add/x=2/y=3
/calc-service/add?x=2&y=3
/calc-service?add&x=2&y=3
/calc-service/x=2/y=3/add
/calc-service/x=2/y=3?add
/calc-service?op=add&x=2&y=3

这些都很好

在查询字符串中使用application/x-www-form-urlencoded参数的好处是 HTML 客户端已经遵循表单处理标准,这些标准会根据用户在表单中提供的数据生成具有该形状的 URI。

但是,任何可以轻松表示为URI 模板的模式都适用于具有适当模板处理级别的客户端。

在某些情况下使用粗粒度表示(想想DTO)可能是有意义的,URI 标识特定的子元素

/calc-service/x=2/y=3#add
/calc-service/x=2/y=3#sub
/calc-service/x=2/y=3#mul

推荐阅读