我目前正在Web服务器上构建外部可访问的API。 Web服务器使用Rails，因此内部变量在snake_case中命名。但是大多数对api的调用都是通过javascript进行的，javascript通常使用lowerCamelCase进行变量命名。
我的问题是：有人可以提出一个策略，用于描述蛇案例变量和驼峰案例变量之间的界限吗？如果服务器接受以camel为例发布的变量，则使用服务器代码（特别是因为路由的params由rails的'convention'部分处理）。或者是否应该强制javascript客户端以蛇形式发布变量，向客户端发布？
欢迎任何和所有想法，但如果某人有来自具有API开发经验的来源的某些文档或信息的链接，那将是理想的。来自Apigee的人建议使用JSON作为默认设置并在他们的Web Api文档中使用camelCase，但我很想知道是否还有其他最佳实践类型的建议。
由于
答案 0 :(得分：0)
快速而令人沮丧的回答：没有人可以为您解答，因为这完全取决于您想要您的界面的样子。 这是一项设计决定。
现在，如果您的客户端将始终使用ajax来访问您的API，那么实际上公开基于camelcase的界面是明智的。
好消息是，没有什么能阻止你充分利用两个世界：只需创建一个camelcase / snakecase转换器类。它会在接收请求时解析params并返回一个规范化的params散列，反过来你的模型会在as_json方法中调用它来返回camelcased密钥。
此解决方案增加了一些开销，但具有使命名约定和转换规则明确的优点，就像ActiveModel::Naming之类的那样。