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

我正在设计我公司正在构建的研究和开发应用程序之一的API层。 API的目的是共享数据库中的数据并提供我们数据的计算功能。Rest API命名约定是否过于冗长？

我的想法是建立一个遵循经典模式中的资源名词控制器端点和休息动词：

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

例如，第一个url可以是任何东西。我反对说它在效率方面应该不会有太大的改变，而且我所建议的设计的自我记录方面的优势将大于（在我看来）非常小的低效率（在每个请求发送的字节数）由更长的路径引入。

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

经典动词 - 名词其余名称惯例是否错误？使用该惯例我看不到任何缺点吗？他是否正在强调该公约效率低下？

我找不到任何人在互联网上抱怨那个会议，我很乐意听取其他意见，甚至是重定向到书籍和链接，这些让我更好地评估这部分设计。

来源

2017-08-26 Jimmy

我没有看到他的设计有任何优势。为什么该ID在描述该ID所代表的内容之前？这对我来说完全是不直观的。他能描述这种设计的“效率”收益吗？因为我没有单独通过URL看到它们。 – David

不要拖延你的想法，但我听说GraphQL是下一个REST –

总之，关于建议的选项。我认为'/ covers？id = {taxEnvId}'会更“有效” –

恕我直言，你的方法似乎更清洁，更容易理解。 API必须直观且易于使用。

来源

2017-08-26 00:54:38 javiergarval

我反对说，它不应该有太大变化：

可能为你工作的一些链接条款的效率

由于变化没有那么不同，那么值得争论吗？如果他是高级工程师，并且组织希望尝试更小的路径方法，那么这是一个帮助组织实现这一目标的机会。如果最终他们对不太详细的URL路径的改变没有改进，那么你可以放心，你帮助得出了这个结论。你必须选择你的战斗，并且这两个URL的外观非常相似，如果在一天结束的时候出现意见，尤其是在团队已经表示有兴趣使URL路径不那么冗长的时候，这并不值得争论。

来源

2017-08-26 02:58:52

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

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

我觉得不是很有效，采用此：

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

试想后盾控制器。 API的类型越多，该控制器将变得越混乱。如果发生这种情况，这怎么可能更有效率呢？网址很短，但网址很便宜。如果他在发送字节上争论，请将他介绍给gzip-compression。

来源

2017-08-26 07:34:22 sschrass

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

回答

相关问题