需要针对Web服务API的一些建议？

Question

我的公司有一款我觉得可以从Web服务API中受益的产品。我们使用MSMQ在后端系统中来回路由消息。目前，我们正在构建一个与Web服务（WCF）进行通信的ASP.Net应用程序，该应用程序又将与我们为MSMQ进行对话。稍后，我们可能会有其他客户端应用程序（不一定使用.Net编写）。进入MSMQ的消息是一个具有由字符串数组组成的属性的对象。还有一个属性包含将通过系统路由的命令（一个字符串）。就我个人而言，我不是这个的忠实粉丝，但我被告知它是为了可扩展性，并且每个系统都可以使用字符串。

关于Web服务，我的想法是根据可传入和传出Web服务的数据对一些对象建模，以便客户端轻松使用它们。最初，我在上面提到的消息对象中传递了字符串数组。我发现我在客户端上创建对象来表示这些数据，使得客户端负责创建这些对象。我觉得Web服务层应该真的在处理这个问题。这就是我一直与服务合作的方式。我这样做是为了让我更方便地在客户端传输数据。

建议我们的小组，我们应该通过提供一个包含命令并拥有一个Web服务来处理所有事情的对象来维护系统中的“单一入口点”。所以，Web服务会有一个方法，我们称之为MakeRequest，它会返回一个对象（序列化的XML或JSON）。建议有一个基础对象，其中可能包含其他对象可以继承的某种类型的命令列表。任何其他对象都可能有自己的命令结构，但仍然继承基本命令。从服务中返回的内容现在还不清楚，但它可能是带有一个代表数据的对象的“消息对象”。我不知道。

我的建议是在我们的实际数据之后建模我们的对象，并为我们正在使用的数据类型创建服务。我们将创建一个基本服务接口，可以容纳所有服务使用的常用方法。因此，例如，GetById，GetByName，GetAll，Save等。特定于给定服务的任何内容都将针对该特定实现来实现。因此，用户服务可能有一个方法GetUserByUsernameAndPassword，但由于它实现了基本接口，它也将包含“基本”方法。根据被调用的服务，我们可以在服务中使用几种方法来返回预期的对象类型。我们可以将所有东西都放在一个服务中，但我仍然希望获得更多可用的东西。我觉得这种方法让客户无法决定要传递什么命令。当我连接到一个用户服务并调用方法GetById（int id）时，我期望获取一个User对象。

当我开始开发WCF服务时，我有幸与MS合作。所以，我对这项技术有了很好的基础和了解，但我不是这次设计它的人。 所以，我不反对“单一切入点”的想法，但任何想法为什么两种方法比其他方法更具扩展性将不胜感激。我以前从来没有使用这种系统的方法来服务层。也许我需要克服？

Answer 1

我认为这两种方法都有优点。

通常，如果您正在编写将由完全独立的开发人员组（也许在另一家公司）使用的API，那么您希望该API尽可能自我解释并且可发现。从消费者的角度来看，具有返回特定对象的特定Web服务方法要容易得多。

但是，许多公司使用Web服务作为其应用程序的许多层之一。在这种情况下，它可能会减少维护以获得通用API。我已经看到一些聪明的机制，不需要对服务进行任何更改，以便将另一列添加到从数据库返回的表中。

我个人的偏好是针对特定的API。我认为具体的方法更容易处理 - 而且主要是自我记录。具体操作需要在某个时候执行，为什么不公开它的原因？如果你写道：

public void MyApiMethod(string operationToPerform, params object[] args) 
{ 
    switch(operationToPerform) 
    { 
     case "InsertCustomer": 
      InsertCustomer(args); 
      break; 
     case "UpdateCustomer": 
      UpdateCustomer(args); 
      break; 
     ... 
     case "Juggle5BallsAtOnce": 
      Juggle5BallsAtOnce(args); 
      break; 
    } 
} 

那么为什么要用Web服务呢？这将会是更好的有：

public void InsertCustomer(Customer customer) 
{ 
    ... 
} 

public void UpdateCustomer(Customer customer) 
{ 
    ... 
} 

... 

public void Juggle5BallsAtOnce(bool useApplesAndEatThemConcurrently) 
{ 
    ... 
}