WCF和ServiceContract版本控制

Question

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

API版本控制的最佳实践？

以下是我从所有这些中取走的

1) REST Uri需要进行版本化。

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

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

2)涉及XML的每个REST资源操作都需要包含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中添加版本。他展示了一种使用重定向的方法，但他的大多数推理都是反对的。我以前对这个问题的回答是这里

这也是值得阅读彼得威廉姆斯帖子的主题。

我几乎只对媒体类型的格式使用XML，根本不使用名称空间。