WCF Rest DataContract 和 ServiceContract 版本控制

Question

我花了很多时间阅读有关 DataContact 和 ServiceContract 版本控制技术的文章：

API 版本控制的最佳实践？

我从所有这些中得出的结论如下：

1) REST Uri 需要进行版本控制。

[http://example.com/v1/car]
[http://example.com/v2/car]

2) 涉及的每个 REST 资源操作XML需要包含XML命名空间

<SampleItemCol xmlns="http://api.sample.com/2011/04/05">
  <Items>
    <SampleItem xmlns="http://api.sample.com/2011/04/01">
      <Test xmlns="http://schemas.datacontract.org/2004/07/WcfRestService2">String content</Test>
      <Id>2147483647</Id>
      <StringValue>String content</StringValue>
      <TestGuid>1627aea5-8e0a-4371-9022-9b504344e724</TestGuid>
    </SampleItem>
    <SampleItem xmlns="http://api.sample.com/2011/04/01">
      <Test xmlns="http://schemas.datacontract.org/2004/07/WcfRestService2">String content</Test>
      <Id>2147483647</Id>
      <StringValue>String content</StringValue>
      <TestGuid>1627aea5-8e0a-4371-9022-9b504344e724</TestGuid>
    </SampleItem>
  </Items>
</SampleItemCol>

所以这是我的问题：

1）假设有数百个数据契约和许多ServiceContracts，维护不同版本和命名空间的最佳类库结构是什么？

2) 如果 Uri 是版本化的，我们是否还需要为 ServiceContracts 指定命名空间？

3）假设有50个数据合约。它们都有命名空间 http://example.com/2011/04/01/ 。如果其中 10 个发生更改并创建了新命名空间，http://example.com/2011/04/ 05/。其他 40 个也应该复制到新的命名空间吗？

我对 REST 命名空间和 URI 版本最关心的是可维护性和类冗余。

预先感谢您的建议和答复！

Answer 1

我沿着这条路线使用了版本化的服务合同和数据合同。这是一场噩梦。最糟糕/最好的部分是，如果您利用超媒体，您实际上根本不需要对 API 进行版本控制。

如果您再次阅读 shonzilla 的帖子，您会发现他实际上并不提倡将版本放入 URI。他展示了一种通过使用重定向来做到这一点的方法，但他的大多数推理都主张反对它。我之前对这个问题的回答是这里

它也值得一读彼得Williams 关于该主题帖子。

我几乎专门使用 XML 作为我的媒体类型的格式，而且我根本不使用命名空间。