Web services 对于支持CRUD操作的RESTful API，我应该有一个或多个复杂类型吗？

我有一个RESTful API支持实体上的CRUD操作。我应该有一个xsd文件来定义所有CRUD操作的模式吗

---

我问这个问题的原因是，我有一些字段只与检索调用相关，而与创建或更新无关。在这种情况下，我应该有一个xsd文件并忽略一些用于创建和更新的字段吗？

如果不同的调用有不同的字段，那么是的，您应该使用不同的xsd文件，但是如果您只保留一些字段为空，这取决于CRUD操作，那么您不需要创建不同的文件。未使用的字段将在那里，但它们将保留为空白。

您的问题似乎将字段的使用与XSD文件的数量联系在一起，这让我认为您可能缺少一些基本的XSD概念

假设您的问题是，对于给定的实体，您可能检索到比您可以更新的字段更多的字段；在一个虚构的

人

实体上演示，您可以R（etrieve）该

姓名

、

地址

、

出生日期

和

自

属性注册，但要C（创建）该实体，您只允许

姓名

，

地址

和

出生日期

-您希望后端系统设置

注册自

属性。需求是尽可能地约束XSD，以提高模型的自描述性

您可以通过创建一个XSD基类型来实现这些场景的分离，然后使用另一个类型对其进行扩展，该类型将包含您想要的额外字段。您可以在一个文件中，或者在两个或更多不同的文件中执行此类操作

<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema targetNamespace="http://tempuri.org/XMLSchema.xsd" elementFormDefault="qualified" xmlns="http://tempuri.org/XMLSchema.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <xsd:complexType name="PersonBase">
        <xsd:sequence>
            <xsd:element name="Name"/>
            <xsd:element name="Address"/>
            <xsd:element name="DateOfBirth"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="PersonToRetrieve">
        <xsd:complexContent>
            <xsd:extension base="PersonBase">
                <xsd:sequence>
                    <xsd:element name="RegisteredSince"/>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
</xsd:schema>

注意：上面的XSD不是为了说明XSD最佳实践

如果您的环境中不允许扩展/限制，那么您可以通过

xsd:group

实现重用—这不会改变我的观点。所以，我基本上是说，你问这个问题的原因-

我有一些字段只与检索调用相关，而与创建或更新无关。

-与XSD文件的数量没有任何关系。。。除非你考虑更多的变量。我会尝试一些我想到的，但我不会提供一个详尽的清单：

• 复杂性：如果您试图解决的问题很简单，那么请尽量使解决方案简单。如上所示，您仍然可以使用一个XSD文件解决“描述性”问题。如果你认为工具是问题空间的一部分，许多工具在XSDs之间的复杂关系中有问题…有时甚至不支持xsd:include，命令行变得更加复杂
• XML名称空间：如果您像我或其他许多人一样，希望将描述业务领域的结构与支持API定义和消息传递的结构分开，那么使用不同的XML名称空间是一种常见的解决方案。您需要与您决定使用的XML名称空间一样多的不同XSD文件。这将促使您拥有多个XSD文件
• 可重用内容：XSD内容可以以多种方式重用。如果您有一个基本类型系统，希望在许多项目/接口中强制执行，那么一个好的做法是在一个或多个单独的XSD文件中编写它们，然后由其他更具体的XSD包含/导入它们
• XML模式重构：如果您所处的环境中有人使用自动重构，那么答案将是：谁在乎？我直接知道新手会觉得这个答案过于自负；然而，在复杂系统的现实生活中，由于个人偏好（代码/模型审查等）和/或各种不同支持级别的工具/平台（包括XSD到代码），一些问题的解决方案实际上很难处理，XSD重构很可能是保持事情顺利运行的唯一方法

---

根据操作的不同，它可以通过以下方式之一处理字段：

• 必需-必须提供且有效
• 可选-此字段仅在提供且有效时使用
• 忽略-服务器忽略此字段。例如，对于createcustomer操作，客户端无法设置ID和createdOn字段，服务器将忽略它们

对于简单的情况，我将使用单个模式元素来定义实体。我将介绍文档中字段的实际使用情况

当不同操作对一个实体的使用存在巨大差异时，单独的实体可能是合适的。例如，管理员的retrieve customer（检索客户）操作可能会返回比普通用户更多的有关客户的信息。如果差异很大，那么如果定义单独的实体，则每个实体都会更容易。您可以使用模式扩展来扩展基础实体，或者简单地从基础实体复制并粘贴字段，只要在您的环境中起作用即可

大多数web服务栈，至少在JAX-RS和JAX-WS中，默认情况下不强制模式遵从性。检查web服务代码中字段的有效性是一个好主意。

我认为，通过询问“有多少XSD文件？”实际上就是询问“有多少独立的元素或复杂类型”。你能解决这个问题吗？文件的数量与此无关，除非我完全忽略了这个问题。