什么是最好的做法在限定的一个肥皂服务(通用与具体操作的)?

StackOverflow https://stackoverflow.com/questions/180572

  •  05-07-2019
  •  | 
  •  

题

我情况如下：

我有一个规范化的数据库，在其中我按住地理信息有关的机场。该结构是：

airport --is in--> city --is in--> country --is in--> continent

现在我要让用户有管理这种数据，而不给予他们直接进入数据库。我们需要提供这种管理界面通过一个网络服务。

现在，当它涉及到设计的服务,我们跑到讨论的有关如何定义的行动。我们提出了不同的解决方案：

方案A：具体操作

每个人四个表格(机场、城市、国家、大陆)我们确定的3操作：

  • 插入
  • 获得
  • 更新

这将导致12个行动2的请求/回应对象=24个对象

创建一个全新的机场与所有依赖性，至少有4个请求是必要的。

方案B：一般

只有一个操作，这是通过控制的参数。这个动作是能够创造必要的一切管理的数据库。

该行动将决定需要做什么和执行它。如果有错误发生，就会滚回一切。

==>1操作=2高度复杂的请求/回应对象

方案C：满足在中1

一个通用操作的每个表，其能够执行获得，插入、更新，就像解决方案B，而是集中在一个表中的每一个。

==>4业务=8复请求/回应对象

方案D：满足在中2

一个通用操作的每个行动的(获得、插入、删除)，其工作可以在每个表并解决依赖关系。

==>3的行动=6略更复杂的请求/回应对象

例

由于这是相当抽象、hier一个简化例为请求对象创造的(肯尼迪国际机场/纽约/美国/北美洲):

方案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似乎相当优雅的给我，因此我试图把这个放在文件:

代码:

<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>

现在我的问题： 这真是最好的解决方案？是的划有足够的了解，什么事？

有帮助吗？

解决方案

大概是你写的一个协议层，这将明白你的不同消息类型。你还需要一个应用程序层分析内容的信息。不同的办法，你提到将转移的负担分析这两者之间层。所以，例如：

方案一:该协议层做所有的分析和返回的数据和命令。该应用程序层可以使用的数据。这也称为RPC模式。

赞成:你可以验证你的信息。你可以地图的消息直接应用程序的话。

缺点：如果你需要作出改变的界面，你的协议的变化。

方案B:该协议层返回的两个价值观和命令。该应用程序层必须使用该指令分析价值观纳入类型。

赞成:该协议从来没有变化。

缺点：你不能验证的信息。你的应用代码的更为复杂。

方案C:该协议层返回两种已知类型和命令，必须进行分析。该应用程序层可以只是分析指令和利用数据。

赞成:我想不出任何似乎不是一个很好的妥协。

缺点：叶的分析只能部分完成。

方案D:该协议层返回已知类型(你的方式实施的)和一个一般命令。该应用程序层必须看看数据接收和转换的通用命令进入一个具体的命令。这是类似于其他建筑。

赞成:电话是不同的操作，以便例如，你可以得到缓的反应。

缺点：复杂性，在应用层

其余的模式通常是以不同方式实现比你有了概述。它使用HTTP GET,POST,放，删除信息通信任意的文件。参数的一部分的网址。所以，例如：

<insert airport="JFK" city="New York" country="USA" continent="North America" />

变得

<insert URL="airport?city=Chicago">ORD</insert>

或者如果您使用的是HTTP它成为一个员额的请求的机场URL与一个参数的城市与内容有关的信息的机场。注意，这些变得更加清晰更多的compliated数据有多个元素和混合类型。例如，如果你想要发送机场的缩写，长名称和高度。

我认为，其他建筑能工作的很好的接口描述。只要所有你需要做的是支持增删改操作。在许多网站，会给你的优点和缺点的其余建筑风格。

我个人喜欢RPC式(方案A)与一些其余的-全属性。我希望该《议定书》的分析工作和验证的信息。这通常是人们如何实施肥皂网服务接口。

你的口看起来可能简单，但今天明天你的一个客户是要问你一个新的呼叫，并不适合其他模型所以好，你会发现自己的楔入到现有的四个信息。

其他提示

这是一个古老的问题，并且我是肯定的服务已经写入前很长一段时间，但我想作出贡献的一个答案了。

在宁静的方法将定义一个机场的资源，例如：

<airport href="/airports/JFK">
    <name>JFK</name>
    <city>New York</city>
    <country>USA</country>
    <continent>North America</continent>
</airport>

或者，如果要使用浏览器的兼容微格式:

<div class="object airport" href="/airports/JFK">
    <ul class="attributes"> 
        <li class="name">JFK</li>
        <li class="city">New York</li>
        <li class="country">USA</li>
        <li class="continent">North America</li>
    </ul>
</div>

此资源将设在一个URI喜欢 /airports/JFK, 将检索到的有一个 GET 方法，更新了一个 PUT 方法，并删除有一个 DELETE 法。

在设计这样，URI /airports/ 会表示容器的资源的所有机场的数据库，并Uri喜欢 /airports/?city=New+York 和 /airports/?country=USA 会被过滤器的容器返回的一个子集的机场。这两个会 GET 方法和资源将包含一系列的机场的资源为上述定义，无论是在全面(因为它们很小)或与几个有用的属性和 href 这一点充分的资源，为每一机场。

最后，添加新的资源也可能是一个 PUT 方法的机场上的完整URI，或 POST 方法上的 /airports/.在这两种情况下身体的请求的机场的资源如上所示。之间的差异的方法是谁来决定的最终URI机场：客户的决定 PUT 和业务决定 POST.这一使用取决于是否或不是你的客户可以合理地确定的权利URI。通常的服务的决定，因为Uri包含一个独特的数字标识符和服务的有选择的。

现在当然你原来的问题是关于肥皂，不休息。我将继续前进，并设立一个宁静的设计如我已经描述，然后描述了我的资源为复杂类型的使用划和肥皂服务与行动重复的 GET, PUT, DELETE, ， POST 操作的宁静的服务。这会给你RPC相当于：

class Airport
    has String name
    has String city
    has String country
    has String continent
    method void update(name, city, country, continent)
    method void delete()

class AirportList
    method Airport[] get(opt name, opt city, opt country, opt continent)
    method void add(name, city, country, continent)
许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top