REST 命名约定 JOIN答案

【问题标题】：REST naming conventions JOINREST 命名约定 JOIN
【发布时间】：2019-11-28 22:35:15
【问题描述】：

我有基本的 get 函数：

app.get('/v1/example', (req, res, next) => {
Connection.query('SELECT * FROM Table1', function (error, results, fields) {...

app.get('/v1/example/:id', (req, res, next) => {...

app.get('/v1/example2', (req, res, next) => {
Connection.query('SELECT * FROM Table2', function (error, results, fields) {...

app.get('/v1/example2/:id', (req, res, next) => {...

当我加入时，它看起来像这样：

app.get('/v1/...', (req, res, next) =>{
Connection.query('SELECT * FROM Table1 LEFT JOIN Table2 ON Table1.TestID = Table2.TestID', function (error, results, fields) {...

我最后一条路由的 REST 命名约定是什么？它必须是 /v1/example3 或 /v1/example1/example2 还是其他？

【问题讨论】：

标签： node.js rest express

【解决方案1】：

REST Api 端点命名与 SQL 查询无关。它更多地是关于您试图通过端点实现的目标。这里有一个非常有用的guideline by Microsoft关于api设计。

【讨论】：

这个“指南”只是总结了现代 REST 架构设计中的不准确之处，通过传播某些信念，当您询问菲尔丁对这件事的看法时，这些信念不一定成立。 IE。 REST 架构中的真正客户端并不关心 URI 是称为 .../orders 还是 .../create-order，因为它不分析 URI 本身，而是依赖于标准化或明确指定的链接关系名称。此外，他们对版本控制的看法肯定与Fielding's view 不同。因此请谨慎使用该“指南”

【解决方案2】：

我想答案应该是 '/v1/example/example2'

因为它说你同时连接了 table1 + table 2

【讨论】：

问题是当我使用'/v1/example/example2'时get函数不起作用。似乎我需要更改“示例”，然后它会再次起作用。为什么我不能使用添加了/example2 的端点'/v1/example'？

【解决方案3】：

我最后一条路由的 REST 命名约定是什么？它必须是 /v1/example3 或 /v1/example1/example2 还是其他？

任何你想要的。

REST 不关心您为资源标识符使用的拼写。见Fielding, 2008。从通用组件的角度来看，URI 只是一个不透明的标识符，类似于代理键或 UUID。任何符合 RFC 3986 中定义的生产规则的拼写都是fine。

app.get('/v1/124003d7-bca4-4a1c-ad3f-5e5e7a900fba', (req, res, next) =>{
    Connection.query(
        'SELECT * FROM Table1 LEFT JOIN Table2 ON Table1.TestID = Table2.TestID',
        function (error, results, fields) {...

这完全令人满意。

我们关心 URI 拼写的原因与我们关心变量名的原因相同；需要阅读它们的人类需要额外的语义上下文来定位自己。例如，如果您正在阅读网络日志，/v1/124003d7-bca4-4a1c-ad3f-5e5e7a900fba 并不能帮助您定位自己。

URI 标识资源，即可以命名的信息 (Fielding, 2000)。因此，如果您正在为标识符寻找人类可读的拼写，您应该考虑返回给客户端的信息——在这种情况下，是您从结果集中构建的报告，而不是考虑该报告是如何生产出来的。

实际上，这是信息隐藏——“如何”被隐藏，可以在不影响消费者的情况下更改。

【讨论】：