旅游

当前位置:手机版美高梅网站 > 旅游 > 不懂点开放平台知识怎么行,公约设计

不懂点开放平台知识怎么行,公约设计

来源:http://www.best-sclae.com 作者:手机版美高梅网站 时间:2019-12-31 05:09

上一篇文章简单介绍了下当前商家开放平台的现状:如何做好商家开放平台(序)

本系列前两篇:

开放即共享,是互联网的一个重要属性和精神。它是一种服务模式,一个特殊的产品,目前较大规模的互联网企业都有自己的开放平台。

从这篇开始主要讨论在建立商家开放平台产品时,有哪些必须要考虑的功能,以及哪些需要注意的坑。

如何做好商家开放平台

如果把自己局限为一个功能产品经理,工作当中只是研究研究产品交互形式、操作流程、表层架构,那确定不太需要知道开放平台相关知识。但如果希望自己能够在较高一层看待产品,那么不光光要熟悉产品本身,还需要知道开放生态,清楚哪些内容可以开放出去,服务什么样的人群?能和哪些垂直领域的优质ISV(独立软件服务商,特指专门从事软件的开发、生产、销售和服务的企业)合作,打造更好的服务生态。

一、开放平台的服务范围

在最开始,我们需要明确开放平台的用户是谁,他的需求是什么,他们的使用场景是什么,在这个时间段如果允许的话需要做一些调研的工作。比如我们的开放平台针对的是旅行社,那么我们需要在所有的工作开始之前走访几家旅行社,看看他们目前存在的内部ERP系统,他们的操作流程和方式。开放平台的另一个服务对象是独立开放商和中小开发者,他们严格意义上不属于开放平台的用户,但是他们对于开放平台的活跃度以及生态的建立是必不可少的,所以也需要兼顾他们的需求。

在确认需求之后,需要考虑将哪些业务开放出去。电子商务内部系统包含的内容很多,且各块之间有着错综复杂的关系,如何将内部系统的各块理顺,抽象出用户关心和需要的点非常重要。我们之前的做法是取最小集,即使在满足用户需求的情况下,开放最小的服务范围,对于不确认的需求暂不提供,待后续明确需求和使用场景后再添加。

明确服务范围和理清各接口之间内部关系还有个好处是便于在wiki中更有条理的说明各接口之间的关系,方便开发者在使用各接口时准确的了解各接口的功能和之前的联系,避免茫然无措的状态。

下面以苏宁云商为例来看看苏宁的商家开放平台。

首先苏宁的开放平台包含了十个部分,请参见下图:

苏宁开放平台范围

上面这些功能几乎涵盖了所有商家在苏宁开店需要使用的功能,是一个相对完善的服务范围。

苏宁开放平台发展了比较长的时间,电商领域也有阿里和京东可以参考,所以平台涵盖的范围和成熟度都较高。我们再看看旅游行业的携程,团队游目前还没有形成开放平台的风气,携程的团队游开放平台还处于探路的阶段。先来看看携程的整个服务范围:

携程开放平台范围

和苏宁不同,携程仅仅开放了商品、价格、库存和订单四块,物流、售前售后、财务等全部没有开放。这既和旅游行业的特殊性相关,比如没有物流,同时也和平台刚刚起步相关。携程选择了最重要的几块作为服务范围,快速的占领第三方,附加功能会在后面的迭代中增加。

如何做好商家开放平台

对接口的理解

二、接口设计

在确定服务范围后,下一步就需要设计接口了。接口是对现有业务场景的抽象,重点是对需求各种场景的把握和接口的粒度。下图是苏宁开放平台商品部分的所有接口。

苏宁开放平台接口

获取产品信息有两个接口,分别为获取产品信息(suning.custom.product.query)和获取产品详细信息接口(suning.custom.productdetail.query),为什么需要有这两个功能类似的接口?实际上这样的接口设计就是根据使用者的需求场景出发的。我们都知道产品系统需要有产品列表页和产品详情页,那么获取产品信息接口就是对应产品列表页的,它只需要简略的产品信息,并且需要一次性展示多条产品。我们在看看这个接口的请求和返回参数:

请求参数:

手机版美高梅网站,返回参数:

从以上参数可以看出,这个接口会一次性返回多条产品,并且具有分页的功能,返回的数据也是产品的一些基本的简略信息,符合在产品列表页使用的特征。

当在列表页看到某个产品,需要详细的了解这个产品的所有信息时,就需要使用到获取产品详细信息的接口了。我们再看看这个接口的请求和返回参数:

请求参数:

返回参数:

由于返回参数过多,我这边删除了部分参数,详细的可以去苏宁开放平台上去查看。这里我们可以看到,获取详细产品信息一次只会返回一个产品(因为产品的ProductCode唯一),并且返回的是产品的所有信息,由此可见,该接口是为了产品详情页设计的。

眼尖的同学可能看到了还有个苏宁产品信息精确查询(suning.custom.product.get),它的请求是产品code和产品名称,返回的是一个产品的简略信息,这个接口又是一个什么使用场景呢?苏宁给的官方使用场景是在修改产品前的商品检索中:

修改产品场景使用到的接口

但是这种场景下,完全可以用产品详情获取接口来代替,所以这个接口并非是必须的。

一个可能的解释是在某些场景下需要通过ProductName来查找产品,但是产品信息获取接口和产品详情获取接口均不符合要求,鉴于开放平台稳定性的要求,无法修改原先的接口,所以增加了这个产品信息精确查询接口来满足需求。(这段纯属猜测,不负任何责任)

我们再来看看携程团队游的接口设计:

携程开放平台接口

这套接口系统初看起来比较简单,甚至是简陋,连基本的查询产品信息接口都没有,这实际上是和旅游行业的需求相关。旅行社大部分都有自己的一套ERP系统,包含了产品、订单、财务、计调等功能,对于不同的分销商,他们会有不同的分销策略。部分产品让携程销售,部分产品让途牛销售,甚至还有统一产品对不同分销渠道的库存切位,所有这些使用场景中,没有明确的需要查询携程产品信息的场景,也没有旅行社提出来某个场景需要,所以保险起见暂时没有提供。这也是为了后续如果有查询产品信息的场景时有更高的自由度,否则可能会出现第一版的接口没人用,但由于已经发布,无法轻易改动,需要开发第二版接口的尴尬。

现在我们分析下,为什么只有更新产品价格接口,而没有新增产品价格接口。其实上这个更新产品价格接口是包含了新增价格的功能的,由于旅游产品是一天一价,所以对于没有价格的日期,则为新增,已经有价格的日期,则为更新。这样设计是基于什么样的考虑呢?我们先看下大部分旅行社ERP系统的价格管理页面:

实际上就是个大的日历框上写明了各种价格,当批量的新增或修改价格时是这样的界面:

在批量操作价格的界面并没有标识是新增还是更新,目的就是将一个时间段内的价格改成目标价,并不关心到底是新增还是更新。所以我们的接口设计时也遵循了这样的规则,没有明确标识新增或更新。

在设计接口之前可以多研究下各大商家接口的设计,尽量与其保持一致,这样保证了开发者能快速理解规则,降低开发的门槛。这就是为什么苏宁、京东、一号店等各大商家开放平台的接口设计和淘宝的开放平台非常相似的原因。我们在学习的同时也不能完全迷信于成熟的开放平台设计,因为平台是比较特殊的产品,接口一旦开放不能随便的修改,所以在演进的过程中可能为了弥补刚开始设计上的缺陷而采取了某些不是特别可取的措施,比如刚才苏宁开放平台上的产品精确查询接口。还有就是平台是一个庞大的系统,即使是成熟的大型公司,也不可能在每个方面都考虑得很清楚,比如苏宁开放平台在接口命名上query和get的混乱使用显得不是很专业。总之就是可借鉴不可照抄。

还没看过瘾?下一篇已新鲜出炉:如何做好商家开放平台(二)

作者:有bigger的产品狗

博客:http://www.jianshu.com/users/63e14c8782f2/latest_articles

本文版权归作者和简书共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

上一篇我们聊过了确认开放平台的服务范围和接口的设计,本篇我们讨论的是接口契约的设计,就是每个接口所包含的字段。有人觉得契约设计是开发人员的职责,其实不然,开发人员(特别是没有产品思维的开发人员)设计契约有几个弊端:1. 包含大量非业务字段,致使契约非常复杂;2. 接口名称字段命名不规范;3. 字段描述偏技术化和公司化,非技术人员或非本公司员工基本无法理解,比如在携程有“可选项”这个名词,如果没在携程干过估计完全无法理解。造成上面这种情况的原因是开发人员对数据库太熟了,所以设计的契约就沿用了数据库的结构和字段名称。

说到开发平台就一定离不开接口,作为pm,我们不需要对接口了解的特别细。只需要知道接口是什么,有什么用,有哪些要素就行。

实际上契约设计直接反映了产品经理对业务的理解程度,需要隐藏部分内部流程和技术上的字段,以免给开发者和用户造成困扰,同时不能遗漏重要字段,需要站在第三方开发者和用户的角度去考虑各种场景,提供最适合的契约。

1、接口是什么。

契约是整个平台设计中非常重要的部分,因为围绕平台开发的大部分时间都需要面对着契约,好的契约设计能让开发者一目了然的知道接口的用处和各字段的含义,而一个不好的设计会让开发摸不到头脑,不得不询问技术支持或者频繁的测试才能完成接口的开发。

生活中我们会接触很多接口,像HDMI接口,USB接口,而且我们知道接入某个接口就能实现某种功能,例如U盘插入电脑USB接口就可以相互传输文件,我们并不需要知道具体是怎么实现的,只需要接入之后能干什么就行。其实从实际意义上讲程序的接口也和硬件一样,将内部实现的功能封装起来,像一个盒子一样只留出一个口子,人们接入这个口子就能使用这个功能。

1. 接口的命名

2、接口有什么用。

首先需要考虑的是接口的名称,好的名称是可以自解释的,看了名字就知道这个接口的用途了。比如taobao.product.add这个接口名称,一看就知道是添加产品接口。再看看苏宁的suning.custom.shelves.move接口,这个乍一看就不知道是干啥的,看了接口名称“商品下架”才发现,本意应该是remove的意思,另外下架一般使用的动词是delisting。

实际开发中,当前端和后端有数据交互时,前端开发人员都会直接向后端询问接口,而不会问他具体的实现,比如APP上需要展现目前天气,那么前端开发直接接入一个天气查询接口就行。另外接口的开放可以帮助第三方应用轻松实现更多功能,如第三方登录、第三方支付等等。

在命名时最好遵循通用的规则,这样可以降低开发人员学习的成本。我列举几个常用的接口动词:

3、接口的几大要点

手机版美高梅网站 1

接口地址——请求的网址。

部分动作对应多于一个的动词,比如新增对应了add和create,但是一套系统中只能选择一个,不要两个都出现。同时尽量避免一套接口在同一个行为下使用不同的动词,比如淘宝开放平台中获得批量结果的接口有的用search,有的用list,这样可能会造成开发者的混淆。

请求方法——一般采用的是HTTP协议的POST和GET请求。

还有就是外面提的比较多的Restful API风格,使用的是Http的动词来表示增删改查这几个动作,目前来看还没有开放平台完全采用这种规则的,当然Restful API风格还是有很多可取之处的,有兴趣可以查看这边文章:RESTful API 设计指南。

请求参数——你传过去是什么内容。

2. 参数传递格式

返回内容——就是你传参数过去之后得到返回的内容,返回内容的格式一般为json或xml格式

说完接口名称,我们在看看参数的传递方式。主流的有两种,一种是组装成指定的格式(一般为json或xml格式)直接post到指定的接口地址,苏宁开放平台就属于这种。另外一种方式是key/value的方式,即key1=value1&key2=value2&...,淘宝开放平台使用的是这种方式。比如淘宝的查询商品信息接口taobao.product.get中的请求参数有product_id、method和fields,那么他的请求url可以是

错误代码——也是返回内容的一部分,当接口发生一些意外情况时,错误代码会告诉你原因。

对于返回参数的格式,基本都比较统一,几乎都支持json和xml两种格式,开发者可以根据自己的使用习惯进行选择。

举个例子,你的APP上要实现查询快递的功能,接入了一个快递查询的接口。作为用户希望的是有一个输入订单号的输入框,点击查询按钮就能够看到快递到哪了。那么输入的快递单号就是请求参数,包裹在什么时候到达哪里就是返回内容。

3. 契约字段的层级

搭建开放平台的目的

所谓字段的层级是契约字段离根节点的级数。淘宝开放平台的字段层级基本都是1,也就是说基本都是根节点这种类似于key/value的形式。例如taobao.product.get接口的应用及输入参数:

1、为第三方开发者提供基础服务

手机版美高梅网站 2

通过开放自身产品服务的各种API接口,让其他开发者在开发应用时根据需求直接调用,例如微信登录、微信支付,支付宝支付、滴滴打车、酒店查询预订等等。我之前呆的一家公司做的是一款商务旅行产品,其中酒店模块接的就是艺龙的接口,能够快速实现基本的查询预订功能。

这种结构容易理解,缺点是对于表示复杂的参数类型时需要自定义结构类型。比如上面的customer_props参数,它其实是一个复杂的类型,里面有多个属性和属性的值,但是由于这种结构的制约,无法做成强类型,只能采用这种pid1:value1;pid2:value2格式。

这样一方面帮助开发者节省大量的时间,另一方面也能宣传自身品牌,最重要的一点就是让第三方产品更好的满足用户需求,假如你做了一个具有较强交易属性的应用,但不接入微信和支付宝支付,即使其他方面做的再好,我相信也没有多少人会使用你的产品。

我们再看个极端的例子,下面是携程团队游开放平台的添加产品信息契约:

2、通过平台的优势引进ISV服务商。

手机版美高梅网站 3

服务商通过入驻平台,将自己开发的产品集成到别人的产品上面,这相当于一种合作模式,两方共同合作打造一站式的服务生态,满足用户的更多需求。

受限于旅游行业的复杂性和携程对商品信息的严苛要求,最终设计了这样的请求报文格式,最大的字段层级高达5级。这样一个复杂的结构如果不在商品内容上做出妥协几乎是不可能用key/value的形式表现出来的。

阿里的钉钉里面就集成了很多第三方应用,像石墨文档、易快报销、微投票等等,大多都是跟企业应用相关的产品,企业管理的所有需求,通过一个钉钉就够。

对于报文的层级这里并不推荐我们携程团队游的做法,开发者接受这样的复杂结构还是有一定难度的。对于key/value形式实在表示不了的,建议将value扩展为json格式,达到表示复杂结构的目的。

再举个例子,饿了么开发平台通过引进ISV,服务市场将提供一站式O2O+门店餐饮服务,从人员招聘、餐饮一体管理软件、硬件设备、图片拍摄、用户营销,甚至法律咨询,满足商家开店经营的几乎所有需求,商家都可以在服务市场尽情挑选饿了么精选入驻的服务商,告别到处咨询打听的麻烦。

4. 字段的命名

3、满足用户的个性化需求。

最后关于字段的命名有两点需要注意:1.命名要统一,如果商品命名为product,就不要在另一个字段中用item或sales来表示商品。2.不要出现拼写错误,不要出现拼写错误,不要出现拼写错误。

正所谓众口难调,一款再好的产品也无法满足用户的所有需求,总存在一些个性化需求。那么通过开放平台,让那些自己有开发能力或开发资源的用户在原基础的服务上进行一些改造,满足自身的特定需求。

下集预告:授权系统。

例如我们熟悉的微信公众号,假设你做了一个电商公众号,想在里面加入商品查询、下单,订单中心、个人中心、订单进度查询等功能,那么就需要第三方平台开发。

博客:

本文版权归作者和简书共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

搭建开放平台的大致流程

1、确定服务对象和范围。

在打算做开发平台之前首先要想清楚开发平台的目标用户群体是谁,能够满足他们什么需求,使用场景是怎么样的等等。例如饿了么、美团外卖,它是一个点餐平台,但不做收银。那些做餐饮管理、做收银的企业就可以通过和外卖平台合作,让商家的收银系统里集成第三方外卖功能,用户在饿了么、美团上点餐,商家可以在收银机上接受他们的消息并处理订单。商家也可以将自己的餐饮管理系统里面商品信息同步到外卖平台的店铺上面。那么这时外卖平台需要开发店铺信息保存接口、商品上传接口、订单状态等接口,来保持两边的数据能够打通。

再比如在饿了么、美团上面开店的商户们可能会在经营时存在资金短缺问题,那么就可以在开发平台上引入提供贷款服务的ISV。

2、接口设计

确定好主要的服务对象和范围之后,接下来要做的就是接口设计。接口设计不是一般PM的工作内容,再说很多做功能设计的PM也不了解这块。这需要技术人员和开发平台产品经理一起完成。

接口设计包括接口命名,传参格式、返回内容、字段命名等。好的命名能让开发者便于阅读和理解,如product.add和product.update,一看就知道商品添加和商品信息更新的接口。

3、授权和审核

授权保障用户和企业数据安全性,不被其他人非法调用。开发平台成立之后就会有开发者进行注册申请,那么我们就需要确定审批规则,申请的接口权限越高,对开发者的资质要求也就越高。

另外对于ISV服务商和商家IT入驻,还需要设计入驻流程、入驻介绍,常见问题等等,ISV入驻大概流程如下:

商务对接——成为服务商——资质审核——创建应用——开发调试——应用审核——应用上架——商务验收

总结:本文对没有接触过开放平台的pm来说是基础性了解,对于接触过的是分享讨论。

本文由手机版美高梅网站发布于旅游,转载请注明出处:不懂点开放平台知识怎么行,公约设计

关键词: