我有一个标准化的数据库,我在其中保存有关机场的地理信息.结构是：
airport --is in--> city --is in--> country --is in--> continent
现在我想让用户管理这些数据,而不是让他们直接访问数据库.我们需要通过Web服务提供此管理界面.
现在,在设计服务时,我们讨论了如何定义操作.我们提出了不同的解决方案：
解决方案A：具体操作
对于四个表(机场,城市,国家,大陆)中的每一个,我们定义了3个操作：
>插入
>得到
>更新
这将导致12个操作,其中2个请求/响应对象= 24个对象
要创建一个包含所有依赖项的全新机场,至少需要4个请求.
解决方案B：通用
只有一个操作,通过参数控制.此操作能够创建管理数据库所需的一切.
该操作将决定需要做什么并执行它.如果发生错误,它将回滚所有内容.
==> 1操作= 2个高度复杂的请求/响应对象
解决方案C：在中间见面1
每个表一个通用操作,它能够执行get,insert,update,就像解决方案B一样,但每个都集中在一个表上.
==> 4个操作= 8个复杂的请求/响应对象
解决方案D：在中间见面2
每个操作一个通用操作(获取,插入,删除),它可以在每个表上工作并解决依赖关系.
==> 3个操作= 6个稍微复杂的请求/响应对象
例
由于这是相当抽象的,所以用于创建请求对象的简化示例(JFK /纽约/美国/北美)：
解决方案A：
要求1/4：
<insertContinent>North America</insertContinent>
要求2/4：
<insertCountry continent="North America">USA</insertCountry>
要求3/4：
<insertCity country="USA">New York</insertCity>
要求4/4：
<insertAirport city="New York">JFK</insertAirport>
解决方案B：
要求1/1：
<action type="insertCountry" parent="North America">USA</action> <action type="insertAirport" parent="New York">JFK</action> <action type="insertContinent" parent="">North America</action> <action type="insertCity" parent="USA">New York</action>
解决方案C：
要求1/4：
<countryAction type="insert" parent="North America">USA</countryAction>
要求2/4：
<airportAction type="insert" parent="New York">JFK</airportAction>
要求3/4：
<continentAction type="insert" parent="">North America</continentAction >
要求4/4：
<cityAction type="insert" parent="USA">New York</cityAction >
解决方案D：
要求1/1：
<insert airport="JFK" city="New York" country="USA" continent="North America" />
解决方案D对我来说似乎相当优雅,因此我尝试将其放在XSD中：
码：
<complexType name="NewContinent">
<sequence>
<element name="NAME" type="string"></element>
</sequence>
</complexType>
<complexType name="NewCountry">
<sequence>
<element name="ISOCODE" type="string"></element>
<element name="NAME" type="string"></element>
<choice>
<element name="newCONTINENT" type="tns:NewContinent"></element>
<element name="CONTINENT" type="string"></element>
</choice>
</sequence>
</complexType>
<complexType name="NewCity">
<sequence>
<element name="IATA" type="string"></element>
<element name="NAME" type="string"></element>
<choice>
<element name="COUNTRY" type="string"></element>
<element name="newCOUNTRY" type="tns:NewCountry"></element>
</choice>
</sequence>
</complexType>
<complexType name="NewAirport">
<sequence>
<element name="IATA" type="string"></element>
<element name="NAME" type="string"></element>
<choice>
<element name="CITY" type="string"></element>
<element name="newCITY" type="tns:NewCity"></element>
</choice>
</sequence>
</complexType>
相应的请求将如下所示：
<complexType name="Request">
<choice>
<element name="AIRPORT" type="tns:NewAirport"></element>
<element name="CITY" type="tns:NewCity"></element>
<element name="COUNTRY" type="tns:NewCountry"></element>
<element name="CONTINENT" type="tns:NewContinent"></element>
</choice>
</complexType>
现在我的问题：这真的是最好的解决方案吗？ XSD是否足以理解,发生了什么？
解决方法
解决方案A：协议层执行所有解析并返回数据和命令.应用程序层可以只使用数据.这也称为RPC模式.
优点：您可以验证您的消息.您可以将消息直接映射到应用程序调用.
缺点：如果您需要对界面进行更改,则协议会发生变化.
解决方案B：协议层返回两个值和一个命令.应用程序层必须使用该命令将值解析为类型.
优点：协议永远不会改变.
缺点：您无法验证消息.您的应用程序代码更复杂.
解决方案C：协议层返回两个已知类型和一个必须解析的命令.应用程序层可以解析命令并使用数据.
优点：我想不出任何,似乎不是一个很好的妥协.
缺点：仅解析部分完成.
解决方案D：协议层返回已知类型(实现它的方式)和通用命令.应用程序层必须查看它接收的数据并将通用命令转换为特定命令.这与REST架构类似.
缺点：应用程序层的复杂性
REST模型的实现方式通常与您概述的不同.它使用HTTP GET,POST,PUT,DELETE消息来传递任意文档.参数作为URL的一部分给出.例如：
<insert airport="JFK" city="New York" country="USA" continent="North America" />
变
<insert URL="airport?city=Chicago">ORD</insert>
或者,如果您正在使用HTTP,它将成为机场URL的POST请求,其中包含城市的参数,其内容是有关机场的信息.请注意,对于具有多个元素和混合类型的更多合并数据,其中一些变得更加清晰.例如,如果您要发送机场缩写,长名称和海拔高度.
我认为REST架构可以很好地适用于您描述的界面.只要你需要做的就是支持CRUD操作.有许多网站可以为您提供REST架构风格的优缺点.
我个人更喜欢RPC样式(解决方案A)和一些REST-ful属性.我希望协议能够进行解析工作并验证消息.这通常是人们实现SOAP Web服务接口的方式.
您的界面今天可能看起来很简单,但明天您的一位客户会要求您拨打一个不太适合REST模型的新电话,并且您会发现自己将其嵌入现有的四条消息中.
