阅读后:
https://restfulapi.net/resource-naming/
当文档具有多个唯一ID时,我有一个问题:重新分级集合中的引用文档。
在链接材料中给出了一个例子:
我们可以使用URI“/customers/{customerId}”标识单个“客户”资源。
或
http://api.example.com/device-management/managed-devices/{device-id}
http://api.example.com/user-management/users/{id}
http://api.example.com/user-management/users/admin我的例子是:
http://myserver/api/courses/{id}它有一个js函数对应物:
app.get('/api/courses/:id', (req, res) =>... 我的问题是,如果我的文档(课程)有两个我想要使用的唯一ID键,我如何维护一个一致的API。
比如ID1 & ID2。
我将如何在快递中编码,以及如何编写url?
因此,如果我需要这两个API是:
http://myserver/api/courses/{id1}
http://myserver/api/courses/{id2}如果我提供两个Express例程:
app.get('/api/courses/:id1', (req, res) =>...
app.get('/api/courses/:id2', (req, res) =>... ID1和ID2都是相同的类型。数字)。REST如何区分这两者?
发布于 2019-07-10 12:23:37
REST不关心资源标识符的拼写。与https://restfulapi.net/resource-naming/所描述的约定一样,约定大致类似于关于拼写变量名称的编码约定。
从REST客户端的角度来看,/api/courses/X和/api/courses/Y是不同的资源--这些资源可能共享相同的底层表示(因为它们是从相同的底层数据构建的),但这是服务器的实现问题。
URI拼写仅受RFC 3986的约束。
/api/courses?id1=12345
/api/courses?id2=67890这是一个非常合理的选择。一个潜在的好处是HTML包含了一个标准,用于创建带有查询参数的URI模板。潜在的缺点是相对引用解析处理查询部分中的非层次数据与路径段中的分层数据不同。
/api/courses/id1/12345
/api/courses/id2/67890完全合理的选择,与相反的权衡从上面。
/api/courses/id1=12345
/api/courses/id2=67890这确实是相同的想法,与上述略有不同的拼写。它具有易读性和可读性的优点。然而,实际使用该模式可能会很有挑战性,这取决于您有什么样的路由支持。
作为URI模板,这些可能看起来像
/api/courses/id1={id}
/api/courses/id2={id}但是,在具有4级URI模板支持的地方,您可能可以使用
/api/courses/{/ids*}另一种可能是使用“矩阵参数”来激发拼写,如
/api/courses;id1=12345
/api/courses;id2=67890同样,这也为您提供了一组不同的权衡,包括可读性、模板支持、相对分辨率支持等等。
另见Stefan Tilkov - 休息:我觉得这不是你想的那样。
发布于 2019-07-10 11:14:41
您需要在url中进行另一个区分,无论是在路径中还是作为查询参数,以便知道要发送哪个字段。默认值为字段#1,另一个为字段#2。
app.get('/api/courses/:id1', (req, res) =>...
app.get('/api/courses/other-key/:id2', (req, res) =>...发布于 2020-03-11 18:38:40
REST的命名约定与express如何确定它不一样。按照OP写路线的方式,特快专递将无法区分那些路线。Express在堆栈中存储路由,并将与最先声明的路由(id1)匹配。id1只是一个表示泛型数据的名称(就像一个作用域变量)。
https://stackoverflow.com/questions/56969324
复制相似问题