我们有一个使用POST的ReST Web服务 - 将数据插入数据库（从XML解组数据），以及GET以检索数据（编组为XML）。
XSD用于生成Java对象（通过Sun的JAXB编译器）来对数据库进行编组/解组数据。 我们认为冻结了 XSD，因为我们认为这样可以完美地模拟数据 - 而且确实如此，但仅限于发布数据。
现在什么时候来自数据库的 GET 数据，我发现自己必须“打破”我们当前的XSD并允许它发布POST类型请求的主键和其他数据值不关心，它们是多余的。
所以 - 实际上XSD现在有可选元素（即那些仅用于GET请求的元素）。当您必须向想要使用您的Web服务的第三方解释并且您在获取和发布数据之间具有某种分裂性格的XSD时，这可能会导致潜在的混淆。它也不像过去那样感觉干净和优雅。
我该怎么办？您的XSD中的元素只能在某些情况下使用（比如获取数据）吗？或者我应该有2个XSD - 一个更详细，为GET请求量身定做，一个是精简的，纯粹是为了POST请求？
您的帮助和建议 - 非常感谢。
答案 0 :(得分：1)
我处于类似情况并创建了一个我用于“阅读”目的的视图。然后我将视图映射到与我的主表相同的XSD，这样我就可以在一个地方管理它。它给了我“松散”阅读的灵活性，而不用担心破坏我的主要数据安排。
答案 1 :(得分：1)
只要您充分记录，只有在某些上下文中使用的字段在XML文档中才可以。 UDDI（是的，我知道，完全没有REST和非冷却的例子）就是这样做的。当您在UDDI中“保存”或“更新”条目时，类似于POST和PUT，您需要在已发布的数据中提供唯一ID，以便服务器知道如何处理它。这里的优点是你有一个架构元素和一个结果数据结构来处理该数据结构上的大多数操作（对于CRU，但在UDDI中并不总是为D）。由于您是RESTful并且可以在资源的URL中表示唯一标识符，因此这种方法可能对您的应用程序没有意义。需要考虑的一件事是，检索后是否要传阅检索到的数据。如果数据需要自包含并在客户端的不同上下文之间或之间传递，那么包含ID可能对您的服务用户有帮助，因为他们不必处理两个数据（实际数据及其唯一标识符）。也就是说，您的客户可能完全抽象出REST / XML交互，在这种情况下，他们的抽象可能已经处理了ID和数据结构的其余字段。