PHP :：构建API包装类

Question

我有一个应用程序，本质上是一个第三方API的包装。该应用程序不使用数据库，只存储一个cookie，这是API所需的会话ID。

API是一个购物系统，它允许用户

-登录/注册/编辑配置文件/注销

-buy商品

-make a捐赠

-become成员

API有大约50个方法，我的应用程序需要连接到这些方法。示例API调用有addItemToBasket()、addDonation()、GetUserDetails()等。

我试图在我的应用程序中找出哪些类应该是类。以下是我到目前为止所拥有的：

类

1) APIManager() 类包含与第三方API中公开的方法一对一匹配的方法，并提供了与远程API服务器连接的机制。这样，用户就可以通过

APIManager->loginUser($sessionKey, $uid, $pwd);

远程API会将用户设置为登录。如果需要，我的应用程序可以通过调用API来检查任何会话密钥的登录状态：

 APIManager->isLoggedIn($sessionKey);

2) User()类--该方法包含处理API调用(如寄存器或登录)之前所需的业务逻辑。一个示例方法是：

function login($_POST) {
    //perform sanity checks, apply business rules etc.
    //if certain conditions are met, we may pass in a promo code, $pc

    APIManager->loginUser($sessionkey, $_POST['uid'], $_POST['pwd'], $pc);
}

我意识到，我可能只是从登录页面调用APIManager，而不是拥有一个用户类本身，但我觉得，由于某些业务逻辑需要在我们真正调用API的loginUser()方法之前运行，所以在用户类中处理它是正确的。我很想知道人们对这件事的看法。

3) 筐()类

篮子是在第三方API中管理的，所以我的应用程序的作用是进行适当的API调用，向篮子中添加新的项目，删除项目，查看篮子等等。我的应用程序在从API中检索数据之前，对篮子一无所知，也不能在没有经过API的情况下对篮子进行任何更改。同样，将这个相关的逻辑分组到一个篮类中也是合适的。前端网页可能会调用以下内容：

Basket->addItem(23);

筐类中的这个addItem()方法看起来如下所示：

addItem($itemID) {
   //perform checks, apply business rules e.g. if user is eligible for discount
        APIManager->addToCart($itemID, $discount);
}

其中addToCart()是第三方API方法，我们调用它来处理项。

4) 捐赠(类)

这样用户就可以捐款了。捐款出现在篮子中，可以从篮子中移除。我只想把一个addDonate()方法添加到购物篮类中，完全不用担心有一个捐赠对象，但是.(见下文)

5) 成员资格()类

..。会员资格实际上是一种捐赠！API将把进入某个帐户的捐赠视为一年的会员，而不是普通的捐赠。我们不能改变第三方API的逻辑/行为。

所以，如果我把50美元捐给“1”账户，那这只是一种正常的捐赠，但如果我把100美元捐给“8”账户，我就会成为会员，享受所有的会员福利(降价，不收邮费等)。

在这里，我不确定设计这个的最佳方法。

如果我创建一个捐赠类，然后用会员来扩展这个类，因为所有的捐赠方法都是会员所要求的。但是成员资格需要额外的方法，如更新()或getExpiry()等。

另外，我应该考虑扩展用户成为会员吗？同样，成员拥有用户拥有的所有核心方法，但也有只有成员才能访问的附加方法，如getSpecialOffers()或getDiscountCode()。

任何关于如何最好地处理设计的指导都是非常感谢的。

谢谢，詹姆斯

Answer 1

就我个人而言，我会在3层构建这个。

第1层： API接口

这一层是对远程API进行实际行级调用的地方.这一层都是关于协议的。这个层中不应该有API特定的内容。所有东西都应该是100%通用的，但是中间层应该能够使用它与API交互。请注意，该层可以来自库或框架之类的其他源。或者你可以自定义写。这一切都取决于你在哪里和你的确切需求。

一些可能属于这里的类：

• XMLRPC_Client
• SOAP_Client
• REST_Client

第2层： API适配器

这一层实际上将API信息硬编码到其中。这基本上是适配器模式。基本上，该层的工作是使用接口层将远程API转换为本地API。因此，根据您的需要，您可以在1:1的庄园中镜像远程API，或者您可以将其弯曲到您的需要上。但是要记住的是，这个类并不是为您的程序提供功能。其目的是将远程API与本地代码分离。通过交换这个类，您的代码应该能够快速地适应使用不同版本的远程API，甚至可能在一起使用不同的远程API。

需要记住的一件重要的事情是，这个Adapter层是用来包含API的。因此，每个单独类的范围都是一个API实现的全部。因此，适配器和远程API之间应该有1:1的映射。

一些可能在这里的类：

• RemoteAPI_v1_5
• RemoteAPI2_v1

第3层：内部对象

这一层应该是不同对象的内部表示(在特定情况下:用户、篮子、购物车、捐赠、成员身份等)。他们不应该直接调用API，而是使用组合(依赖注入)成为API的基本桥。通过保持它的分离，您应该能够完全独立于内部类来改变API (反之亦然)。

因此，您的一个类可能如下所示：

class User {
    protected $api;
    public function __construct(iAPIAdapter $api) {
        $this->api = $api;
    }
    public function login() {
        $this->api->loginUser($blah);
    }
}

这样，就不需要真正的API管理器了。只需在程序开始时创建API的一个新实例，并将其传递给您的其余代码。但它的主要好处是非常灵活，因为您应该能够更改API(无论是版本还是调用本身)，只需在代码中交换适配器层(当您实例化适配器时)。其他一切都应该正常工作，您应该与代码或远程API的更改完全隔离开来(更不用说，如果以这种方式构建，它应该是非常可测试的).

那是我的0.02美元。这可能有点过分，但这取决于你的确切需要.

Answer 2

我想说：

1. 创建一个包含所有需要的捐赠类
2. 创建成员的成员变量(应该是捐赠类型的)。
3. 您可以在成员类中拥有这样的方法： 公共函数makeDonation($data) {$this->$data=新的捐赠($data) //可能带有数据参数；$this->贡献者->commit()/不管它做什么来设置事情.不管你需要什么}

这样，您就可以很好地在项目之间进行解耦。此外，捐赠应该实现一个迭代面，这样如果以后行为被改变，它仍然应该包含memeber类所需的方法。

这种方式比继承更灵活。不久前，我问了一个类似的问题，得到了一个很好的答案：

奇怪的多重继承的优雅选择