RESTful

REST真的完全适合微服务架构吗?

【编者的话】作者根据自己的微服务经验,提出REST并不是微服务的唯一通信机制,从而介绍了微服务的几种通信机制,包括REST、管道以及基于异步消息传递。同时,作者提出了在不同的场景下可以使用不同的通信机制。

在我接触微服务的这段时间,大部分关于如何安装部署微服务的线上样例或文章都一致认为REST是微服务之间通信的唯一方式。因此,你可能理所当然地认为REST就是微服务的一种标准,并且是设计与实现微服务系统一种方式。然而,并非如此。…

RESTful API 设计最佳实践

来源:http://www.oschina.net/translate/best-practices-for-a-pragmatic-restful-api

数据模型已经稳定,接下来你可能需要为web(网站)应用创建一个公开的API(应用程序编程接口)。需要认识到这样一个问题:一旦API发布后,就很难对它做很大的改动并且保持像先前一样的正确性。现在,网络上有很多关于API设计的思路。但是在全部案例中没有一种被广泛采纳的标准,有很多的选择:你接受什么样的格式?如何认证?API应该被版本化吗?

在为SupportFu(一个轻量级的Zendesk替换实现)设计API时,对于这些问题我尽量得出一些务实的答案。我的目标是设计这样一个API,它容易使用和采纳,足够灵活去为我们用户接口去埋单。…

理解本真的REST架构风格

本文是“深入探索REST”专栏系列深度内容中的第二篇,它将带您领略REST架构的起源、与Web的关系、REST架构的本质及特性,以及REST架构与其他架构风格之间的比较。

引子

在移动互联网、云计算迅猛发展的今天,作为一名Web开发者,如果您还没听说过“REST”这个buzzword,显然已经落伍了。夸张点说,甚至“出了门都不好意思跟别人打招呼”。尽管如此,对于REST这个泊来品的理解,大多数人(包括一些资深的架构师)仍然停留在“盲人摸象”的阶段。常常听到各种各样关于REST的说法,例如:有人说:“我们这套新的API决定不用Web Service(SOAP+WSDL),而是直接使用HTTP+JSON,也就是用RESTful的方式来开发。” 不用SOAP,甚至也不用XML,就自动变成了RESTful了。还有人认为:REST与传统的Web Service其实没有本质区别,只是对于URI的构造方式提出了更多要求,而这些要求Web Service完全都可以实现。潜台词是:既生瑜,何生亮。Web Service已经足够好了,干嘛还要再折腾什么REST。这些对于REST的不同说法,果真如此吗?REST究竟是什么?是一种新的技术、一种新的架构、还是一种新的规范?

对于这些问题笔者先不解答,为了深入理解REST是什么,我们需要回顾一下Web发展的最初年代,从源头上讲讲REST是怎么得来的。…

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