是否有任何关于REST API的命名约定准则？
在创建REST API时，API中是否有命名约定或实际标准（例如：URL端点路径组件，查询字符串参数）？ 骆驼帽是常态还是强调？ 其他？
例如：
api.service.com/helloWorld/userId/x
要么
api.service.com/hello_world/user_id/x
注意：这不是RESTful API设计的问题，而是用于最终路径组件和/或查询字符串参数的命名约定准则。
任何指导方针将不胜感激。
我认为你应该避免骆驼帽。 规范是使用小写字母。 我也会避免使用下划线并使用破折号
所以你的URL应该是这样的（忽略你所要求的设计问题:-)）
api.service.com/hello-world/user-id/x
Dropbox，Twitter，Google Web Services和Facebook的REST API全部使用下划线。
仔细查看URI的普通网络资源。 那些是你的模板。 考虑目录树; 使用简单的类似Linux的文件和目录名称。
HelloWorld不是一个非常好的资源类。 它似乎不是一个“事物”。 它可能是，但它不是很像名词般的。 greeting是一件事情。
user-id可能是您正在提取的名词。 然而，可疑的是，您的请求的结果只是一个user_id。 请求的结果更可能是用户。 因此， user是您正在提取的名词
www.example.com/greeting/user/x/
我感觉合理。 专注于使您的REST请求成为一种名词短语 - 通过层次结构（或分类法或目录）的路径。 尽可能使用最简单的名词，尽可能避免名词短语。
一般来说，复合名词短语通常意味着层次结构中的另一步。 所以你没有/hello-world/user/和/hello-universe/user/ 。 你有/hello/world/user/和hello/universe/user/ 。 或者可能/world/hello/user/和/universe/hello/user/ 。
重点是提供资源之间的导航路径。
链接地址: http://www.djcxy.com/p/71371.html上一篇: Are there any naming convention guidelines for REST APIs?