blocks|key|2574559|text|所有的评论都对可能的解决方案有一些很好的反馈。你必须要问的问题是，你的嵌套资源是否包含在内。包含不允许对资源进行寻址，因此，它是根据其包含的父级进行版本控制的。例如，考虑一个订单及其相关的行项目。行项目通常不应单独寻址。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2574560|如果您有相关但不同的可寻址资源，则任何一种资源都不应直接提供相关资源。这引入了耦合。在REST中解决这个问题的方法是使用HATEOAS。有许多方法可以实现HATEOAS，但只有几个标准提供了指导。关于如何实现HATEOAS没有一个正确的答案，但它可能看起来像这样：|2574561|Bar+v1.1|offset|length|style|CODE|2574562|{
++"field_one":+"String",
++"field_two":+"String",
++"links":+[
++++{+"name":+"Foo",+"href":+"http://localhost/foo/123"+}
++]
}|code-block|syntax|javascript|2574563|这使得Bar可以链接到Foo，而不需要依赖于它。这与使用指向相关页面的超链接组成网站的方式相同。|2574564|在实现HATEOAS时，还需要注意以下几点：|2574565|2574566|根据统一接口约束，URL是标识符(而不是人类可能推断的123+)|unordered-list-item|2574567|您应该使用绝对链接URL，因为相关资源可能不在同一主机上，客户端不应该弄清楚这一点。|2574568|虽然常见，但按URL段进行版本控制在这里会导致问题，因为服务器如何知道如何使用适当的版本生成链接？其他方法，如媒体类型、查询字符串，甚至报头都不会受到此影响。归根结底，客户端负责知道要请求哪个API版本。服务器永远不可能知道客户端想要什么。除非服务器保证版本对称性，否则客户端很可能会被绑定到不一致的API版本(例如:+Foo+1.0和Bar+1.1)。如果所有API都必须具有相同的受支持版本，即使没有更改，实施版本对称性也可能很困难或很慢。我也见过用来解决网址段问题的网址模板，但是--再说一次--客户端不应该知道或理解模板语法。|2574569|2574570|希望这可以作为你设计的起点。|2574571|entityMap^0|0|0|0|8|0|0|0|0|0|R|3|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|17|8|@$F|18|G|19|H|I]]|9|@]|A|$]]|$1|J|3|K|5|L|7|1A|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1C|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1E|8|@$F|1F|G|1G|H|I]]|9|@]|A|$]]|$1|W|3|X|5|V|7|1H|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|V|7|1I|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1K|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|14|$]]

All of the comments have some good feedback on possible solutions. The question you have to ask is whether your nested resource is contained. Containment doesn't allow a resource to be addressed and, thus, it's versioned according to its contained parent. For example, consider an Order and its related Line Items. A line item typically should not be addressable on its own.

If you have related, but different, addressable resources, any one resource should not directly provide a related resource. This introduces coupling. The way to solve this in REST is to use HATEOAS. There are many ways that HATEOAS can be achieved and only a few standards that provide any guidance. There is no one right answer on how to implement HATEOAS, but it might look something like:

<code>Bar v1.1</code>

<pre><code>{
 "field_one": "String",
 "field_two": "String",
 "links": [
 { "name": "Foo", "href": "http://localhost/foo/123" }
 ]
}
</code></pre>

This enables Bar to link to a Foo without having a hard dependency on it. This is same way that websites are composed using hyperlinks to related pages.

Here's a few more notes that you should consider when implementing HATEOAS:

<ul>
<li>In accordance with the Uniform Interface constraint, the URL is the identifier (and not <code>123</code> as a human being might infer)</li>
<li>You should use absolute link URLs because the related resource may not be at the same host and the client should not have to figure that out.</li>
<li>Though common, versioning by URL segment causes a problem here because how does the server know how to generate links with an appropriate API version? Other methods such as media type, query string, or even header do not suffer from this. Ultimately, the client is responsible for knowing which API version to ask for. There is no way for the server to ever know what the client wants. Unless the server guarantees version symmetry, it's quite possible that clients will be bound to incongruent API versions (ex: Foo 1.0 and Bar 1.1). Enforcing version symmetry can be difficult or slow if all APIs have to have the same supported versions, even when there are no changes. I've also seen URL templates used to solve the URL segment issue, but - again - the client shouldn't have to know or understand a template syntax.</li>
</ul>

May this be useful as a starting point to your designs.

I'm migrating some API endpoints to a more concise way. 
But I'm having some issues about how to handle nested objects.

For example:

I have an object <code>Foo</code> and a <code>Bar</code>.

<code>Foo v1.0</code>

<pre><code>{
 "field_one": "String",
 "field_two": "String"
}
</code></pre>

<code>Foo v1.1</code>

<pre><code>{
 "field_one": "String",
 "field_two": "String",
 "field_three": "String"
}
</code></pre>

<code>Bar v1.0</code>

<pre><code>{
 "foo": "Foo",
 "field_one": "String",
 "field_two": "String"
}
</code></pre>

For an endpoint to get <code>Foo</code> the version is pretty straightforward, is <code>v1.0</code> or <code>v1.1</code>, 
but how do I handle an endpoint for <code>Bar</code>? Every change to a child should "generate"
a new version for the parent? How to handle if the parent have more than one versioned child?
If <code>Bar</code> has another child <code>Baz</code> with two different versions, the versioning of <code>Bar</code> will keep
going with the iterations of the children?

<pre><code>Bar v1.0 -&gt; Foo v1.0
Bar v1.1 -&gt; Foo v1.1
Bar v2.0 -&gt; Foo v1.1 + Baz v1.0
</code></pre>

How to make it straightforward so, if the consumer want to use the <code>Foo v1.1</code> on his whole application, he knows which version of <code>Bar</code> should he get? Just documentation or there are some pattern behind it?

API versioning of Entities with children

服务器

我正在将一些API端点迁移到一种更简洁的方式。但是我有一些关于如何处理嵌套对象的问题。例如：我有一个对象Foo和一个Bar。Foo v1.0{  "field_one": "String",  "field_two": "String"}Foo v1.1{  "field_one": "String",  "field...

问具有子级的实体的API版本控制
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问具有子级的实体的API版本控制EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问具有子级的实体的API版本控制
EN