API 管理简史及其发展方向,api管理系统php源码

本文将讨论API 管理简史及其发展方向,api管理系统php源码。

“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 目录的概念出现的地方。考虑此类目录的一种方法是将其视为组织数字产品的企业资源规划 (ERP) 工具。理想情况下，这样的工具可以提供所有数字产品的通用和统一可见性，并且可以轻松适应提供这些产品的任何技术平台。

API产品营销

API 产品管理是当今现代管理的立足点。它提供了一种以统一的方式管理 API 产品的方法，并且不会过度限制 API 的开发和部署方式。然而，它仍然是一种提供 API 产品的模式，但它们并没有积极地向潜在消费者推销。

推测管理的下一个演变步骤是 API 产品营销可能并不太牵强。与所有产品一样，产品的价值不在于它们的存在，而在于它们被消费了。这意味着与任何其他产品类别一样，在营销 API 中发挥更积极的作用很有意义。

这个更积极的角色遵循产品营销的通常路径：了解消费者，了解他们的痛点，了解并清楚地记录这些副产品如何解决这些痛点，然后将这些产品营销到目标群体。

对于 API 管理，这意味着在目录之上构建以消费者为中心的工具，例如门户和市场，并使用这些工具积极营销 API，了解消费，并将其反馈到 API 产品营销和 API 开发中。

这最后的演进步骤仍处于起步阶段，但鉴于 API 在数字化转型中日益重要以及经济运作方式，它很可能会成为 API 管理的下一个主要演进阶段。

上一章起了个头，这一章咱们亲身做一下这个api的基础结构。

我们给它叫做“老赵api系统”。

首先，我们要做的这个api系统是私有的，不开源的，不分发给其它人一起用（当然你非要大力推广，也随便你）。

其次，我故意遗漏了一个小小的点子，这个点子我自己用，我也是怕我这个办法泄露后会有安全问题。

就当是抛砖引玉吧。

先说要注意的几点：

0、不要使用默认首页

1、不使用session和cookie

2、每次访问都需要验证用户名密码

3、任何单个文件都不允许能正常运行

4、任何单个文件都不允许能单独实现任何功能

5、未验证成功身份时不输出任何错误提示

相信很多高人一看这几条就会知道我要怎么做。也会有一部分人会嗤之以鼻说太初级。

管他呢，反正这是我自己摸索出来的，就是黑客黑我也只能在操作系统方面下手，在我这套系统里他永远不可能有成功的访问请求。

下面详细说：

0、不要使用默认首页。

如果你的环境里首页设置了很多，比如index.php,index.html,default.html,default.php之类的，那么你api的接口文件一定不能用这些，比如你可以用ilaozhao_xx_api.php，这谁猜得到？

1、不使用session和cookie。

cookie是用明文存在于用户端的，很容易查看和修改，这个大家都清楚。而php的session也依赖于cookie来存储一个session_id。并且我们的api要每次访问就返回一次数据，很多访问方法并不会存储cookie，这会导致session失效。

2、每次访问都验证用户名密码。

现在流行那个啥叫token的方式，我懒得研究，倒不如每次都验证用户名和密码，这样等密码泄露后只要我改一个密码，他那边立马就不能用了。都不用等他那边信息过期。当然我们不能明文传递这些东西，需要做一定加密处理。

3、任何单个文件都不允许能正常运行。

资源文件夹不能有任何可执行文件。并且尽量多分几个文件，所有的文件相互依赖，并且把它们互相组织起来的文件又是另一个单独文件，这样即便别人知道了我们的文件路径和文件名，当访问这个文件时，也无法正常运行。

4、任何单个文件都不允许能单独实现任何功能。

某个文件要实现功能，必须依赖其它文件内的函数或类，并且当前文件不能知道这些函数和类具体在哪个文件里实现的。这样即便这个文件的源代码泄露，对方也不知道里面的依赖关系，不会连累到其它文件。

5、未验证成功身份时不输出任何错误提示。

在用户名密码出错时，系统不要输出任何有用的信息，或者输出一个假的404信息，这样别人在试探我们的系统时，根本不知道是哪一步出错了，而我们的客户端可以根据里面的暗语来判断状态。

我做一个小例子来说明一下，这个小例子只是抛砖引玉，并不是我最终的代码样子。

文件树结构：

老赵api文件树结构

根目录下只有一个文件夹，整个api系统都通过一个接口文件”dayelaiwana.php”来调用。

怎么样，不知道文件结构的人根本猜不对你有哪些文件，也就不能访问任何文件。

下面的代码没有使用太先进的语法，比如类和对象啊命名空间啊啥的，新版本php添了好多特性，但我比较倾向于不去使用它们，我要尽量的让代码对环境没有要求，在尽可能多的版本环境下都能运行。

毕竟我们要的是安全，而不是让所有人能读懂我们的代码。

我们要尽可能的不使用教科书上的通用的写法，尽可能搞一套自己的写法。

下面是dayelaiwana.php的代码：

<?php
//接口文件，单独调用这个文件没任何作用，参数必须得对，差一个字母这个文件都运行不出个毛线来。
//而参数是你自己定的，可随意加密修改。
//当然你还可以把这个路径也放到变量里，然后藏起来。
include "./ilaozhao_funs/postget.php"; //没有依赖，但也不实现任何具体功能
include "./ilaozhao_funs/login.php"; //依赖pdo,dbfuns,postget和接口文件
include "./ilaozhao_funs/curl.php"; //没有依赖，但也不实现任何具体功能
include "./ilaozhao_funs/dbfuns.php"; //依赖pdo和接口文件
//上面这些文件里涉及到安全的功能都有依赖，并且他们不知道要用的函数在哪
//全靠这个接口文件把它们组合到一起
//并且上面的函数里也会用到接口文件的函数(就是下面那个)
//这些因素缺一不可，只能由接口文件来整合他们
//上面这些文件和其它的api文件，都无法单独运行。不是缺这就是缺那。
//下面这俩函数是故意没单独放文件里的，为的就是其它文件缺少这个接口文件时在调用这个函数时会出错。
function output2die($msg, $code = -1, $data = ''){
    $diemsg['code'] = $code;
    $diemsg['msg'] = $msg;
	$diemsg['data'] = $data;
    echo json_encode($diemsg);
    die();
}
function isphone($phonenumber)
{
    return preg_match("/^1[3-9]d{9}$/", $phonenumber);
}
$area = post("area");//要使用的api种类
$class = post("class");//要使用的api小分类
$fun = post("fun");//要使用的api功能
//清理post
unset($_post['area']);
unset($_post['class']);
unset($_post['fun']);
if ($class !== false && $fun !== false){
    
	if ($area == false){
		$area = "public";
	}
    
	//生成api文件全名，这里没加密，你可以自己变动这里。
    $incfile = dirname(__file__)."/{$area}/{$class}/{$fun}.php";
    if (file_exists($incfile)){ //检查api文件是否存在，其实不检查也行。
		include "./config/pdodb.php"; //创建数据库连接，依赖接口文件
        include $incfile;//将单独的api文件导入进来
    }else{
		//我因为调试的原因，显示了错误信息，要求高的可以去掉。
		output2die("无效的请求", -1);
    }
}else{
	output2die("无效的请求", -2);
}

文件我写了注释，方便大家看，实际在使用时不能有这些注释，这些注释只能方便别人破解我们的系统，并且这个接口文件尽可能进行代码混淆加密。

然后是一个获得当前用户信息的小例子api，这个api文件存在了
/ilaozhao_api/public/login/usrmsg.php里面。在调用时大概url是这样：

https://你的域名/ilaozhao_api/dayelaiwana.php

post数据为：{
key:"用户名密码时间加密字符串运算后的结果",
class:"login",
fun:"usrmsg",
username:"该用户的用户名"
}

api代码内容usrmsg.php为：

<?php
//示例文件，得到当前用户的所有信息
//文件依赖：接口文件、数据库连接文件、dbfuns文件、login文件
//单独访问这个文件根本不能运行
//依赖关系完全靠接口文件处理
//这个api读取post参数中的username
checkusernamepassword(); //检查用户名密码，不对真接就终止运行了，对了的话就可以运行下面的代码
$dbarr['username'] = post("username");
if($dbarr['username'] !== false){ //这一步没必要，能验证过上面那个函数，这个参数肯定存在，但我就是写了，就是玩儿
	//一定要用pdo的绑定功能访问数据库，这种方式能避免sql注入。
	$sql = "select * from tb_users where users_username = :username";
	$rec = db_query($sql,$dbarr);
	if($rec['count'] > 0){
		output2die("成功。",1,$rec);
	}else{
		output2die("找不到该用户。",-1); //要求高的，不要输出错误信息。
	}
}
output2die("失败",-2); //要求高的，不要输出错误信息。

这里面的checkusernamepassword()函数（在ilaozhao_funs文件夹内的login.php文件里）也比较关键：

<?php
/**
 * 判断用户名密码的函数
 此函数不允许返回东西
 调用的时候直接调用
 用户正常自然没反应
 用户不正常，这个函数直接结束程序运行。
 */
function checkusernamepassword(){
	$keystr = "这里是加密字符串，这个串只有你自己知道是什么。";
	
	$key = post("key"); //这个key是客户端把用户名密码时间加密字符串运算后的结果
	//用当前日期当第二密钥，这个作用是每天的密钥都不一样。
	//即便被拦截了，也算不出规律来，当然源码泄露了就不行了。
	//不能太精确，因为客户端与服务器端的时间不可能完全一样。
	$keystr_today = date('ymd',time());
	
	//访问数据库，一定要用pdo的这个参数方式。
	//这个方式在代入数据与直接写在sql语句里不一样。
	//sql注入在这种使用方式下完全不会生效。
	$sqlpar['username'] = post("username"); //这个没加密的必要，这个在输入框里就能看到，而且也会在很多地方显示。
	if($sqlpar['username'] === false || $key === false){
		//非法调用
	}
	
	//不要在sql里直接比对用户名密码
	//而且传过来的数据也没有密码
	//要取出该用户的记录，然后计算后与传过来的加密身份信息对比
	$sql = "select * from tb_users where username=:username"; //你可以在这limit 1
	$rec = db_query($sql, $sqlpar);
	if($rec['count'] > 0){
		
		$keyindb = md5(md5($keystr).md5($rec['rows'][0]['username']).md5($keystr_today).md5($rec['rows'][0]['password']));
		//上面这句是加密方式，把加密字符串、用户名、当前日期、密码的md5连接起来并再计算一次md5
		//当然你还可以再加点别的东西，比如字符串反转，以及其它变量之类的。
		//上面这句计算出来的和$key中的一样时，说明密码是对的。
		if($key == $keyindb){
			//用户名密码对
			//此时我们啥也不做
			//或者你想设置某些变量也行
		}else{
			//否则
			die(); //结束程序运行，
		}
	}
}

代码里都有注释，应该能看清楚。而且还有其它的自定义函数我就不放代码了。

这样我们在扩充api时只需要在对应路径下写php代码文件就行，而且很多函数可以直接使用，不用include任何文件。

而且这个系统内所有的文件在单独访问时都会出错（可以设置php不显示错误信息），而接口文件在参数不正确的情况下也不会有什么具体运行结果。

也没有默认的首页文档可以访问。

文件路径和文件名都没规律，在网上都查不到参考。

那么想黑掉这套api只有两个办法：

0、黑掉服务器操作系统，再从文件系统入手。

1、破解客户端代码或者拦截访问数据，找到访问规律。

这两点暂时无能为力解决。

**边写文档边写代码，头有点乱，可能有遗漏的东西，不知道大家能不能看懂。

**此api系统还有很多地方可以进一步加密处理，但我个人感觉没必要了。已经够可以了。

**此代码没有使用太先进的语法，比如类啊命名空间啊啥的，新版本php添了好多特性，但我比较倾向于不去使用它们，我要尽量的让代码对环境没有要求，在尽可能多的版本环境下都能运行。

毕竟我们要的是安全，而不是让所有人能读懂我们的代码。

上述就是小编为大家整理的API 管理简史及其发展方向,api管理系统php源码。