web-services – 定义soap服务(通用 *** 作与特定 *** 作)的最佳实践是什么？

概述我的情况如下： 我有一个标准化的数据库,我在其中保存有关机场的地理信息.结构是： airport --is in--> city --is in--> country --is in--> continent 现在我想让用户管理这些数据,而不是让他们直接访问数据库.我们需要通过Web服务提供此管理界面. 现在,在设计服务时,我们讨论了如何定义 *** 作.我们提出了不同的解决方案： 解决方案A：具体 *** 作 我的情况如下：

我有一个标准化的数据库,我在其中保存有关机场的地理信息.结构是：

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模型的新电话,并且您会发现自己将其嵌入现有的四条消息中.

总结

以上是内存溢出为你收集整理的web-services – 定义soap服务(通用 *** 作与特定 *** 作)的最佳实践是什么？全部内容，希望文章能够帮你解决web-services – 定义soap服务(通用 *** 作与特定 *** 作)的最佳实践是什么？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。