API

关于 php json API接口开发的注意问题

关于 php json接口开发的注意问题

一是注意跨域问题.需要加 Access-Control-Allow-Origin:*  http头.(针对于前端浏览器脚本调用接口)

二是如果请求的header里  Content-Type: 是 application/json,则需要用 file_get_contents(“php://input”);接收.如果用 swoole 框架的话,需要用$request->rawContent()接收.

如果请求header里Contente-Type是 multipart/form-data,或application/x-www-form-urlencoded
则需要用 $_POST($_GET)或$_FILES来接收.

Ps :js 代码调用接口示例如下

1.要加contentType: “application/json; charset=utf-8”,

2.需要使用JSON.stringify 转换json对象或把对象转为字符形式,如'{“aa”:22}'(json两边加单引号)

var submit_sync = function() {  
    $.ajax({  
        type: "post",  
        url: 'add-post-json.php',  
        async: false, // 使用同步方式  
        

服务端指南 | 良好的 API 设计指南

设计一套良好的 API 接口。

版本号

在 RESTful API 中,API 接口应该尽量兼容之前的版本。但是,在实际业务开发场景中,可能随着业务需求的不断迭代,现有的 API 接口无法支持旧版本的适配,此时如果强制升级服务端的 API 接口将导致客户端旧有功能出现故障。实际上,Web 端是部署在服务器,因此它可以很容易为了适配服务端的新的 API 接口进行版本升级,然而像 Android 端、IOS 端、PC 端等其他客户端是运行在用户的机器上,因此当前产品很难做到适配新的服务端的 API 接口,从而出现功能故障,这种情况下,用户必须升级产品到最新的版本才能正常使用。

为了解决这个版本不兼容问题,在设计 RESTful API 的一种实用的做法是使用版本号。一般情况下,我们会在 url 中保留版本号,并同时兼容多个版本。

GET】 /v1/users/ // 版本 v1 的查询用户列表的 API 接口

写一个接口应该考虑哪些内容?

我觉得写一个接口应该考虑如下的内容:

  1. 确定 url:是否符合 Restful,是否要符合公司确定的规范?
  2. 确认操作人的权限
  3. 确定要操作的资源的权限
  4. 验证传入的参数:不要相信外面传进来的任何数据
  5. 操作失败的提示
  6. 操作成功的提示
  7. 写文档:如何按规矩写好文档是一件值得花时间和精力梳理的事情
  8. 如何测试接口,用什么数据测试

App架构设计经验谈:接口的设计

App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉。

安全机制的设计

现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是无状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息。实现上,大部分都采用token的认证方式,一般流程是:

  1. 用户用密码登录成功后,服务器返回token给客户端;
  2. 客户端将token保存在本地,发起后续的相关请求时,将token发回给服务器;

REST API 安全设计指南

REST API 安全设计指南。REST的全称是REpresentational State Transfer,它利用传统Web特点,提出提出一个既适于客户端应用又适于服务端的应用的、统一架构,极大程度上统一及简化了网站架构设计。

目前在三种主流的Web服务实现方案中,REST模式服务相比复杂的SOAP和XML-RPC对比来讲,更加简洁,越来越多的web服务开始使用REST设计并实现。但其缺少安全特性,《REST API 安全设计指南》就是一个REST API安全设计的指南,权当抛砖引玉,推荐网站后台设计及网站架构师们阅读。…

设计不使用oauth身份验证的安全restful api

调用api客户端程序,需要在header处发送 

API_ID: 1

API_TIME: 时间戳

API_HASH:  $clienthash

$user=”username”;

$publicKey=’hello’;

$privateKey=  hash_hmac(‘sha256’, $user, $publicKey); 需要先把客户端程序的privateKey存入数据库.

$data=json字符串.

$clienthash = hash_hmac(‘sha256’, API_TIME.API_ID.$data, $privateKey);

API端验证:

$serverHash = hash_hmac(‘sha256’, API_TIME.API_ID.$data, $privateKey);//到数据库查找此客户端的privateKey;

如何实现RESTful Web API的身份验证

最近想拿一个小项目来试水RESTful Web API,项目只有几个调用,比较简单,但同样需要身份验证,如果是传统的网站的话,那不用说,肯定是用户名+密码在登录页获得登录Token,并把登录Token记在Cookie和Session中作为身份标识的这种方式,但现在不同了,关键是RESTful,这意味着我们设计出来的这些API是无状态的(Stateless),下一次的调用请求和这一次的调用请求应该是完全无关的,也就是说,正宗的RESTful Web API应该是每次调用都应该包含了完整的信息,没错,包括身份信息!

那如何确保安全?传输时给密码做MD5加密?得了吧!这样做只能让你自己感觉“安全”点,其实没什么任何用处,利用现在的技术(有种叫什么Rainbow Table啥的来着?本人外行,不是很懂)很快就能算出明文密码了,而且如何防止挟持和重发攻击?

也许你想到了,SSL,如果你打算采用SSL,请忘记一切自行设计的加密方案,因为SSL已经帮你做好了一切,包括防止监听,防止挟持,防止重发……一切都帮你考虑好了,你大胆地把明文密码写在你的包中就OK了,我向你保证没问题。

但SSL的缺点是服务器端配置相对有点复杂,更关键的就是客户端对此支持可能不好,那你考虑一种自己的加密方法,有木有?我这里提供一种方法,思路来自于:http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/,我只是把上面的内容中整理了一下变成了我的方法。(传说中的剽窃?呵呵)方法描述如下:…