[设计]-OpenAPI中的callback机制

OpenAPI提供给外部网站访问，为了便于讨论，我们把接口提供方定义为Resource Provider，简称RP，使用方定义为Caller。 通常而言，我们在OpenAPI的设计原则中，要求Caller到RP是必须是单向访问的，只有这样，才能解除两个网站的双向耦合。但是实际中，有时候还真存在需求，不得不让RP访问到Caller，我们把这个情况叫Callback。我想举两个例子来说明这种情况。 网上银行支付 做过支付宝支付的都清楚，商家扣款必须把调用发到支付宝（RP），但是这笔支付究竟是否成功，需要支付宝回调来确认，以及支持成功后最终返回到一个支付成功的展示界面。在这个场景中，就用到了callback机制。 跨网站的好友确认 网站A和网站B深度合作，网站A的用户可以加网站B的用户为好友。假设网站A发起一个到网站B OpenAPI的call, call的url大致是：api.do?method=addFriend&a_uid=1234&b_uid=4321。 但是，我们知道，通常一个网站的加好友是必须经过对方确认的，这样麻烦就来了。这个请求发送后，并不知道这个b_uid是否接受，也不知道什么时候接受？所以，就必须设计一个callback的机制，让RP回调caller，解决这类异步的确认问题。 好了，有了上面两个引子，我们可以讨论OpenAPI的callback机制了。 在编程语言中，其实很早就存在callback的做法了。比如在C语言中，通常是把一个函数指针作为参数传入到某个method内部，只要确保这个函数指针的生命周期在回调的时候还存在，即可执行。对于OpenAPI其实也一样。我们可以设想，在OpenAPI的传入参数中引入callback_url, 来让RP回调.   值得补充的是，光有一个callback_url 参数是不太够的。为什么呢？ method + callback_url 只能表达一个method对应一个callback,  如果一个method有多个callback呢，就需要额外的参数来表达。所以，建议可以在引入一个 callback_type 的参数。RP在拿到（method, callback_type)后可以根据callback_type来判断是什么情况，从而进行不同的处理，然后进行回调。 很多时候，RP并不会在caller调用后立即callback，而是需要等待内部某些事件发生的时候才callback。这样RP内部就需要把这些callback需求存储下来。 接下来讨论一个问题，callback_url如果需要一些参数怎么办？比如在加好友的这个例子中，B网站的用户确认好友关系后，还需要在发起callback_url调用时把a_uid和b_uid告诉网站A.  当然，这就回到了网站A的OpenAPI规范了。这个问题很好解决，只是引申出来，对于OpenAPI的规划，并不是接口包装那么容易，需要考虑到很多因素。也反映了我们为什么一直提到的一个设计原则：尽量单向依赖