API管理方法及系统 【技术领域】
本发明涉及地理信息系统领域，尤其涉及一种API管理方法及系统。
背景技术
目前，基于互联网的地图搜索服务随着Ajax技术的提出，已经从性能上得到很大的提升，不仅在速度上还是用户体验上，它都已经超越了传统的方式。但是开发一个完整的地图搜索服务系统，需要在人力和技术上投入很高的成本，同时由于其专业性，使很多企业望其项背。这样的情况下，地图API应运而生。
地图API(Application Programming Interface，应用程序编程接口)通过编程语言把各种搜索服务、地图显示、地图操作工具以控件的形式提供给用户，这些控件通过不同的指定接口名称来调用。这样就把系统的复杂性隐藏在控件下面，而用户只需要的面对一个简单的API，这样就大大加快了开发的效率和难度。
然而发明人发现现有技术中在使用地图API进行二次开发时，地图API的提供方都是直接将该地图API文件提供给用户，用户接收到所述地图API文件后，将其写入进行开发的系统中，然后用户配置相关信息来获取API提供的各种功能，同时由于用户开发后的系统运行时需要调用所述API对应的资源，因而上述地图API的提供方也需要把地图API所使用的资源如图片、控制页面显示的样式等一起提供给用户，导致所述API文件与用户开发的系统耦合过紧。
【发明内容】
本发明的实施例提供一种API管理方法及系统，在用户使用API进行二次开发时，实现API文件与用户采用所述API文件开发的系统解耦。
为达到上述目的，本发明的实施例采用如下技术方案：
一种API管理方法，API服务端统一保存API文件和其对应的资源，该方法包括：
接收目标系统通过预设用户接口发送的API文件调用其对应资源的请求，所述目标系统为采用从所述API服务端获取的API文件开发得到的系统；
根据所述API文件调用其对应资源的请求从指定目录中获取所述API文件对应的资源；
通过预设用户接口发送所述资源给所述目标系统，由所述目标系统中的所述API文件进行调用。
一种API管理系统，包括：
目标系统，采用从API服务端获取的API文件开发得到的，用于通过预设用户接口向所述API服务端发送所述API文件调用其对应资源的请求；
API服务端，用于统一保存API文件和其对应的资源，并根据所述API文件调用其对应资源的请求从指定目录中获取所述API文件对应的资源，通过预设用户接口发送所述资源给所述目标系统；
所述目标系统还用于接收所述API服务端返回的所述API文件对应的资源，由所述API文件进行调用。
一种API服务端，API服务端统一保存API文件和其对应的资源，所述API服务端包括：第一接收单元，用于接收目标系统通过预设用户接口发送的API文件调用其对应资源的请求，所述目标系统为采用从所述API服务端获取的API文件开发得到的系统；
第一获取单元，用于根据所述API文件调用其对应资源的请求从指定目录中获取所述API文件对应的资源；
第一发送单元，用于通过预设用户接口发送所述资源给所述目标系统，由所述目标系统中的所述API文件进行调用。
本发明实施例提供的API管理方法，由API服务端统一保存API文件和其对应的资源，采用从所述API服务端获取的API文件开发得到目标系统，通过接收目标系统通过预设用户接口发送的API文件调用其对应资源的请求，并根据所述API文件调用其对应资源的请求从指定目录中获取所述API文件对应的资源，然后通过预设用户接口发送所述资源给所述目标系统，由所述目标系统中的所述API文件进行调用。本技术方案在实现时通过所述目标系统采用的API文件从所述API服务端获得，而所述目标系统运行时，所述API文件也是从所述API服务端中调用对应的资源，因而解决了现有技术中由于直接将所述API文件对应的资源给使用所述API文件进行目标系统开发的用户，导致所述API文件与采用所述API文件开发的系统之间耦合过紧的问题。同时，由于本方案无需将所述API文件对应的资源直接给使用API文件的开发者，也就避免了现有技术中每次有新版本的API时，就需要重新将所述新版本的API文件及其对应资源传给API文件的使用者，从而导致对API文件进行管理时不便捷的问题。
【附图说明】
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为实施例1中API管理方法的流程图；
图2为实施例1中API管理系统的结构图；
图3为实施例1中API服务端的结构框图；
图4为实施例2中API管理方法的流程图；
图5为实施例2中API管理系统的结构图；
图6为实施例2中API服务端的结构框图。
【具体实施方式】
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
实施例1：
本发明实施例提供一种API管理方法，其中API服务端统一保存API文件和其对应的资源，如图1所示，该方法包括如下步骤：
101、接收目标系统通过预设用户接口发送的API文件调用其对应资源的请求，所述目标系统为采用从所述API服务端获取的API文件开发得到的系统。
由所述API服务端对所述API文件及其对应的资源进行统一管理。与现有技术直接所述API文件及其对应的资源给使用者相比，在有API文件的版本更新时，便于对所述API文件及其对应的资源进行管理。
102、根据所述API文件调用其对应资源的请求从指定目录中获取所述API文件对应的资源。所述资源如API文件需要调用的图片或控制页面显示的样式，在所述目标系统运行时调用该资源来保证该目标系统可以正确的运行。所述API文件及其对应的资源都保存在所述API服务端的指定目录中。所述API文件调用其对应资源的请求中包含了所述API文件对应的类型和版本号，通过所述API文件对应的类型和版本号就可以从指定目录中获取所述API文件对应的资源。
103、通过预设用户接口发送所述资源给所述目标系统，由所述目标系统中的所述API文件进行调用。在所述目标系统运行时，由所述API文件通过预设用户接口从API服务端调用其对应的资源，解决了现有技术中由于直接将所述API文件对应的资源给使用所述API文件进行目标系统开发的人员，导致所述API文件与采用所述API文件开发的系统之间耦合过紧的问题。
为了实现上述方法，本实施例还提供一种API管理系统，如图2所示，所述API管理系统包括：目标系统21和API服务端22。
目标系统21采用从API服务端获取的API文件开发得到的，用于通过预设用户接口向所述API服务端发送所述API文件调用其对应资源的请求。所述API文件及其对应的资源都保存在所述API服务端的指定目录中。API服务端22用于统一保存API文件和其对应的资源，并根据所述API文件调用其对应资源的请求从指定目录中获取所述API文件对应的资源，通过预设用户接口发送所述资源给所述目标系统。
所述目标系统21还用于接收所述API服务端返回的所述API文件对应的资源，由所述API文件进行调用。由于所述目标系统采用的API文件从所述API服务端获得，而所述目标系统运行时，所述API文件也是从所述API服务端中调用对应的资源，解决了现有技术中由于直接将所述API文件对应的资源给使用所述API文件进行目标系统开发的用户，导致所述API文件与采用所述API文件开发的系统之间耦合过紧的问题。
本发明实施例还提供一种API服务端，API服务端统一保存API文件和其对应的资源，如图3所示，所述API服务端包括：第一接收单元31、第一获取单元32和第一发送单元33。
第一接收单元31用于接收目标系统通过预设用户接口发送的API文件调用其对应资源的请求，所述目标系统为采用从所述API服务端获取的API文件开发得到的系统。所述预设用户接口是提供给所述API文件的使用者和采用所述API文件开发得到的目标系统进行访问API服务端的唯一接口。第一获取单元32用于根据所述API文件调用其对应资源的请求从指定目录中获取所述API文件对应的资源。
第一发送单元33用于通过预设用户接口发送所述资源给所述目标系统，由所述目标系统中的所述API文件进行调用。由于无需将所述API文件对应的资源也给使用所述API文件进行目标系统开发的人员，实现了API文件与用户采用所述API文件开发的系统解耦。
实施例2：
本发明实施例详细介绍一种API管理方法，如图4所示，该方法包括如下步骤：
401、在用户端从API服务端调用所需API文件进行二次开发之前，在API服务端提供的注册页面中进行用户端的信息注册。
所述API服务端接收所述用户端的注册信息，并在所述用户端注册完成后，通过所述预设用户接口发送许可Key给所述用户端。每个所述许可Key唯一对应一个用户端。用户端接收到所述许可Key后将其保存，并在从所述API服务端调用所需API文件前发送给所述API服务端。
402、所述用户端通过所述预设用户接口发送的所述许可Ke y、所需API类型和版本号给所述API服务端。所述API类型可以为JavaScript或者Flex，根据开发所述API文件时采用的编程语言而定。所述API版本号可以为1.0、1.02等，根据所述API文件版本的更新情况，由所述API文件的开发者确定。
403、所述API服务端接收所述用户端通过所述预设用户接口发送的所述许可Key、所需API类型和版本号。然后从所述指定目录中获取所述API类型和版本号对应的API文件并通过所述预设用户接口发送所述获取到的API文件给所述用户端。
所述用户端接收到所述API文件后，利用所述API文件进行开发得到目标系统。由于所述API服务端对所述API文件及其对应的资源进行统一管理。与现有技术直接所述API文件及其对应的资源给使用者相比，在有API文件的版本更新时，便于对所述API文件及其对应的资源进行管理。
404、所述目标系统在运行时，所述API文件调用其对应的资源之前，所述API服务端接收目标系统通过预设用户接口发送的API文件调用其对应资源的请求。
405、所述API服务端根据所述API文件调用其对应资源的请求从指定目录中获取所述API文件对应的资源。所述API文件及其对应的资源都保存在所述API服务端的指定目录中。所述API文件调用其对应资源的请求中包含了所述API文件对应的类型和版本号，通过所述API文件对应的类型和版本号就可以从指定目录中获取所述API文件对应的资源。
406、所述API服务端通过预设用户接口发送所述资源给所述目标系统，由所述目标系统中的所述API文件进行调用。在所述目标系统运行时，由所述API文件通过预设用户接口从API服务端调用其对应的资源，解决了现有技术中由于直接将所述API文件对应的资源给使用所述API文件进行目标系统开发的人员，导致所述API文件与采用所述API文件开发的系统之间耦合过紧的问题。
在用户使用所述目标系统进行查询时，所述API服务端还提供一种查询接口，所述目标系统中API文件可以通过该查询接口调用地图引擎接口进行相关查询操作。如：用户在使用所述目标系统时希望查询北京饭店相关的信息，则当用户在所述目标系统上输入北京饭店进行查询时，所述目标系统中API文件会通过预设用户接口访问所述API服务端，然后通过调用所述API服务端中上述查询接口访问所述地图引擎，当从该地图引擎上获取到北京饭店的相关信息后，返回给用户。该查询过程属于API文件内部调用过程，对于用户来说，该过程是透明的，也就是用户利用所述API文件进行二次开发时，不需要关心所述查询过程。
另外，本发明实施例中的所述API文件可以通过下述开发步骤获得：首先API开发端的开发小组在SVN服务端建立API开发的工程，然后在小组内共享并协同开发，开发过程中不断进行API的更新。所述API工程基本开发完成后，由测试人员从SVN服务端获取，测试人员从SVN服务端获取到最后版本的API文件时并与开发人员迭代进行测试，测试通过后确定所述API文件的版本号，并把所述API文件和其所使用的资源发布到所述API服务端。每个版本的API文件都提供一个相应的API文档，为用户在使用所述API文件进行二次开发时提供参考。然后进行下一版本的开发与测试，如此循环。
所述API服务端可以采用步骤407至步骤409(图未示)管理所述API文件及其对应的资源：
407、依次接收API开发端发布的每个API文件和其对应的资源。
408、在所述指定目录中的类型子目录下为所述接收到的每个API文件创建对应的目标版本目录。所述指定目录的结构可以采用但不限于下述目录结构：{server}/{type}/{vers ion}/{API文件及相关资源}；其中，serve表示该系统中的指定目录；type为API的类型目标，表示所述API文件对应的类型；version为版本号目录，所述API文件及相关资源存放于所述API文件对应的类型目录下的版本子目录中。
409、将所述接收到的每个API文件和其对应的资源依次保存到各自对应的所述目标版本目录下。
本实施例还提供一种API管理系统，如图5所示，所述API管理系统包括：目标系统51、API服务端52、用户端53。
所述用户端53用于在所述API服务端进行注册；所述API服务端52用于在所述用户端53注册完成后，通过所述预设用户接口发送许可Key给所述用户端53。所述用户端53还用于通过所述预设用户接口向所述API服务端发送所述许可Key、所需API类型和版本号。
然后，所述API服务端52还用于从指定目录中获取所述API类型和版本号对应的API文件，通过所述预设用户接口发送所述获取到的API文件给所述用户端53。所述用户端53还用于利用所述API文件开发得到所述目标系统51。
目标系统51采用从API服务端获取的API文件开发得到的，用于通过预设用户接口向所述API服务端发送所述API文件调用其对应资源的请求。所述API文件及其对应的资源都保存在所述API服务端52的指定目录中。API服务端52还用于统一保存API文件和其对应的资源，并根据所述API文件调用其对应资源的请求从指定目录中获取所述API文件对应的资源，通过预设用户接口发送所述资源给所述目标系统51。
所述目标系统51还用于接收所述API服务端返回的所述API文件对应的资源，由所述API文件进行调用。由于所述目标系统采用的API文件从所述API服务端获得，而所述目标系统运行时，所述API文件也是从所述API服务端中调用对应的资源，解决了现有技术中由于直接将所述API文件对应的资源给使用所述API文件进行目标系统开发的用户，导致所述API文件与采用所述API文件开发的系统之间耦合过紧的问题。同时也方便对所述API文件在有版本更新时进行管理。
所述API管理系统，可选的，还可以包括：API开发端54，用于开发API文件，并将确定版本号的API文件和其对应的资源发布到API服务端52。所述API服务端52还用于在指定目录中的类型子目录下为所述发布的每个API文件创建对应的目标版本目录，将所述发布的每个API文件和其对应的资源保存到各自对应的所述目标版本目录下。
本发明实施例还提供一种API服务端，如图6所示，所述API服务端包括：第一接收单元61、第一获取单元62、第一发送单元63、第二接收单元64、第二获取单元65、第二发送单元66。
其中，第二接收单元64用于接收所述用户端通过所述预设用户接口发送的所需API类型和版本号。第二获取单元65用于从所述指定目录中获取所述API类型和版本号对应的API文件。第二发送单元66用于通过所述预设用户接口发送所述获取到的API文件给所述用户端。所述用户端获取到所述API文件后，采用所述API文件进行二次开发得到目标系统。
然后，所述目标系统运行时，第一接收单元61用于接收目标系统通过预设用户接口发送的API文件调用其对应资源的请求，所述目标系统为采用从所述API服务端获取的API文件开发得到的系统。所述预设用户接口是提供给所述API文件的使用者和采用所述API文件开发得到的目标系统进行访问API服务端的唯一接口。第一获取单元62用于根据所述API文件调用其对应资源的请求从指定目录中获取所述API文件对应的资源。
第一发送单元63用于通过预设用户接口发送所述资源给所述目标系统，由所述目标系统中的所述API文件进行调用。由于无需将所述API文件对应的资源也给使用所述API文件进行目标系统开发的人员，实现了API文件与用户采用所述API文件开发的系统解耦。
本发明实施例主要应用于地理信息系统，实现了API文件与用户采用所述API文件开发的系统解耦。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。