Question

我正在设计我公司正在构建的研究和开发应用程序之一的API层。 API的目的是共享数据库中的数据并为我们的数据提供计算功能。

我的想法是构建遵循经典模式资源名词和其余动词的Controller端点：

GET /api/v1/{organisations}
GET /api/v1/{organisations}/{id}
GET /api/v1/{organisations}/{id}/{offices}

等

开发人员给我的项目强烈建议我不会使用这个惯例，他说公司正在放弃这个惯例，因为它太冗长，因此效率不高。

他建议采用结构较少的端点。这样的东西，来自代码：

GET /api/v1/{taxEnvId}/covers 
GET /api/v1/{coverId}/occupclasses

例如，第一个网址可以是任何内容。

我反对说它在效率方面不应该有太大的变化，并且我自己设计的自我记录方面的优势将大于（在我看来）非常小的设计由较长路径引入的低效率（按每个请求发送的字节数）。

他比我更有经验，所以我想知道我是否在当前的设计中犯了错误。

经典动词 - 名词休息名称约定是否错误？在使用该惯例时我是否有任何不足之处？他是否正确地强调该公约效率低下？

我无法在互联网上找到任何抱怨该约定的人，我很乐意听取其他意见，甚至重定向到书籍和链接，这使我对这部分设计的评价更好。

Answer 1

恕我直言，你的方法看起来更干净，更容易理解。 API必须直观且易于使用。

一些可能适合您的链接：

Answer 2

我反对说它在效率方面不应该改变很多

由于变化没有那么不同，那么值得争论吗？如果他是高级工程师并且组织想要尝试更小的路径方法，那么这是帮助组织实现这一目标的机会。如果最终他们对较不详细的URL路径的更改导致没有改进，您可以放心，您帮助得出了这个结论。你必须选择你的战斗，这两个网址看起来非常相似，如果最终归结为意见，那么不值得争论，特别是当团队已经表示有兴趣使URL路径更简洁时。 / p>

Answer 3

如果您（公司）不仅提供数据，还提供API中的功能，那么Rest是一个很好的方法。否则GraphQL可能是一件事，两者基本上都是different。简而言之：如果你不提供商业逻辑，GraphQL会发光。

我认为你的方法是/v1，因为那不是资源。版本控制本身就是主题。

我觉得采用这个方法效率不高：

GET /api/v1/{taxEnvId}/covers 
GET /api/v1/{coverId}/occupclasses

想象一下支持控制器。 API具有的类型越多，该控制器就越混乱。如果发生这种情况，这怎么可能更有效率或效率呢？网址很短，但网址很便宜。如果他正在争论发送的字节，请将他介绍给gzip-compression。

Rest API命名约定是否过于冗长？

3 个答案: