具有List属性的REST资源 [英] REST resource with a List property

问题描述

我想要一些有关当前体系结构的反馈.

I'd like some feedback on my current architecture.

我有一个人"资源，该资源可通过GET和PUT请求提供给/users/people/{key}.该资源产生并接受JSON格式的人"对象.

I have a "Person" resource that is available through GET and PUT requests to: /users/people/{key}. The resource produces and accepts "Person" objects in JSON format.

这是GET /users/people/{key}可能返回的JSON的示例:

This is an example of the JSON that GET /users/people/{key} might return:

{
 "age":29,
 "firstName":"Chiquita",
 "phoneNumbers":[
   {"key":"49fnfnsa0sas","number":"555-555-5555","deleted":false}
   {"key":"838943bdfb-f","number":"777-777-7777","deleted":false}
  ]
}

如您所见，人"具有一些典型的字段，例如名字"和年龄"，以及更复杂的集合类型字段:"phoneNumbers".

As you can see, "Person" has some typical fields such as "firstName" and "age" as well as a trickier collection-type field: "phoneNumbers".

我正在尝试设计资源，以便在更新资源时，客户端仅需要发回需要更新的字段.例如，仅更新此人的名字:

I'm trying to design the resources so that when updating them, the client only needs to send back the fields that need to be updated. For example, to update only the person's firstName:

PUT users/people/{key}

{
 "firstName":"New first name",
}

这样，来回传输的不必要信息要少得多(取决于资源的大小，数量级会减少)

This way there is a lot less unnecessary information being transferred back and forth (degrees of magnitude less depending on the size of the the resource)

我的问题是，该如何处理列表属性(例如"phoneNumbers").我是否应该编写一些更复杂的代码来检查旧列表中的现有PhoneNumber键，如果未引用它们则不触摸它们，如果有匹配的键则更新它们，如果有带有新键的PhoneNumber则添加它们?还是我应该编写一些更简单的代码，将每个"phoneNumbers"列表属性视为仅包含在"PUT"请求正文中的另一个完全被覆盖的字段?是否存在一种公认的标准方法，其中一种策略已被证明比另一种策略的问题少?还是我可以自行决定?

My question is, what should I do with the list properties such as "phoneNumbers." Should I write some more complex code that examines the existing PhoneNumber keys in the old list and doesn't touch them if they are not referenced, updates them if there is a matching key, and adds them if there is a PhoneNumber with a new key? Or should I write some simpler code that treats each "phoneNumbers" list property as just another field that is completely overwritten if it is included in the "PUT" request body? Is there a standard accepted approach to this where one strategy has been proven to be less problematic than another? or am I to use my discretion?

谢谢！

推荐答案

我认为，每次更改某项内容时，仅让客户端上载当前人的所有信息是最有意义的.但是，如果满足以下条件，这可能是不够的:

I'm thinking it'd make the most sense to simply have the client upload all the info for the current person every time something is changed. However, this might not be adequate if:

• 在典型情况下，每次更改都必须来回发送大量数据.
• 多个人可以同时编辑同一个人.

如果您的人员对象很大，则可以考虑采用差异/补丁方法.发送新版本之前，请将其与旧版本进行比较.如果单身人士栏位(例如firstName)发生变更，只需在JSON物件中列出即可:

If your people objects are large, you might consider taking a diff/patch approach. Before sending the new version, compare it to the old version. If a singleton field (e.g. firstName) changed, simply list it in your JSON object:

{
 "firstName":"New first name"
}

对于电话号码数组，请按键列出要删除的电话号码，然后像通常一样列出要添加的新电话号码.像这样:

For the array of phone numbers, list the phone numbers to remove by key, and list the new phone numbers to add like you normally would. Something like this:

{
 "+phoneNumbers":[
  {"key":"123456789abc","number":"555-123-4567"}
 ],
 "-phoneNumbers":[
  "49fnfnsa0sas"
 ]
}

您还可以Google搜索"json diff"，看看您发现的任何结果是否有帮助.

You could also Google search "json diff" and see if any of the results you find are helpful.

正如我之前所说，除非您有充分的理由要介绍这种复杂的深度，否则最好让客户端重新上传整个person对象以进行更新.

As I said before, unless you have a compelling reason to go to this depth of complexity, it's probably best to just have the client re-upload the entire person object to update it.

这篇关于具有List属性的REST资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！