RESTAPI-架构方面需要的意见

我正在设计一个RESTAPI。我现在正在做的部分只涉及从服务器读取JSON数据形式的对象并对其进行修改

我考虑用于此目的的资源如下所示： /数据/{表名}/{行键}

我想允许对该资源执行

GET

和

PUT

操作

我正在努力解决的问题是，我希望与JSON对象一起返回其他数据，如客户消息、往返数据库所需的时间等。。。我还想允许在URL太长的情况下发送带有有效负载的查询参数，如果URL包含在其中的话

---

因此，资源的工作方式如下：

获取

GET /data/{table name}/{row key}

PUT GET /data/{table name}/{row key}

服务器返回：

{
   data:{...JSON OBJECT GOES HERE ....},
   message:"customer messages go here",
   responseTime:'123ms',
   otherInfo:"Yada yada yada;
}

PUT

GET /data/{table name}/{row key}

PUT GET /data/{table name}/{row key}

客户端作为有效负载发送：

{
   data:{...JSON object goes here...},
   queryArguments:{...extra long query arguments go here...}
}

我担心这可能会违反RESTful

GET

和

PUT

资源的规则，因为您发送到服务器的内容并不完全是您要返回的内容，因为其他信息包含在有效负载中。我不想让每一次手术都成为一种补救措施

我是不是太固执了？我是否应该用其他方式来组织这件事

谢谢

编辑：：：

---

我应该注意到，在参考资料：

/data/{table name}/{row key}

中，为了简单起见，我使用了“table name”和“row key”。这是用于noSQL数据库的。此资源的工作方式与AmazonS3类似。“uuid”实际上比“row key”更好的描述。

我看不出这有什么错，在我看来很标准。我不确定您计划在

queryArguments

中传递什么，您是在这里指定要为JSON-P客户端执行的回调吗？我建议您记住的唯一一件事是REST处理资源，而这不一定与表一一对应。与其使用行键，不如使用某种类型的GUID或UUID，以便映射到该资源。

至于我，这取决于如何使用其他信息。对于我的客户来说，响应时间不是一个问题（或者至少我这么认为：），他们只需要那个响应。对于作为开发人员的我来说，它可以帮助调试。所以，当客户给我慢请求时，我可以轻松地测试它，而这些额外的信息可能会有所帮助。这里我的意思是，可以按照您指定的/data/{table name}/{row key}创建简单的url，并根据该请求发送响应，您可以再创建一个url/data/{table name}/{row key}/debug或其他任何东西，以获得具有“reponseTime”等附加信息的相同数据。只是一个想法；）

---

更新：啊，是的，忘记了：不要将表名作为url的一部分，至少要修改它的名称。我不想告诉任何人我的表是如何被调用的，如果有人要侵入我的DB注入额外的代码，我希望她花更多的时间寻找任何信息，而不是把信息放在一个盘子里：）

我认为你的方法没有错。
但是，如果我实施这个场景，我会问自己以下问题：

谁是我的资源

客户信息是资源的一部分吗

“响应时间”是资源的一部分吗

让我们以“响应时间”为例。如果它是您资源的一部分，那么您的方法是完美的，不应该做任何其他事情。

---

但是，如果它不是资源的一部分，则将其作为HTTP头返回。很公平。

这个布局看起来很像Shoji：