API

服务端指南 | 良好的 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);//到数据库查找此客户端的

                    

如何实现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/,我只是把上面的内容中整理了一下变成了我的方法。(传说中的剽窃?呵呵)方法描述如下:…