深入理解什么是RESTful API

前言:最近两年很火爆的网络框架Retrofit,使用它的时候,查看文档会告诉你,要求后台的服务器哥们必须符合REST规范给你设计接口,作为安卓开发工程师来说,我就很奇怪了,REST规范到底是啥?本着极客精神,我就查了资料,写了这么一篇文章,如果有不对的地方,欢迎提意见。 一、理解RESTful架构 越来越多的人开始意识到,网站即软件,而且是一种新型的软件。 这种”互联网软件”采用客户端/服务器模式,建立在分布式体系上,通过互联网通信,具有高延时(high latency)、高并发等特点。 网站开发,完全可以采用软件开发的模式。但是传统上,软件和网络是两个不同的领域,很少有交集;软件开发主要针对单机环境,网络则主要研究系统之间的通信。互联网的兴起,使得这两个领域开始融合,现在我们必须考虑,如何开发在互联网环境中使用的软件。 RESTful架构,就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便,所以正得到越来越多网站的采用。 但是,到底什么是RESTful架构,并不是一个容易说清楚的问题。下面,我就谈谈我理解的RESTful架构。 一、起源 REST这个词,是Roy Thomas Fielding在他2000年的博士论文中提出的。 Fielding是一个非常重要的人,他是HTTP协议(1.0版和1.1版)的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席。所以,他的这篇论文一经发表,就引起了关注,并且立即对互联网开发产生了深远的影响。 他这样介绍论文的写作目的: 本文研究计算机科学两大前沿—-软件和网络—-的交叉点。长期以来,软件研究主要关注软件设计的分类、设计方法的演化,很少客观地评估不同的设计选择对系统行为的影响。而相反地,网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现,常常忽视了一个事实,那就是改变应用程序的互动风格比改变互动协议,对整体表现有更大的影响。我这篇文章的写作目的,就是想在符合架构原理的前提下,理解和评估以网络为基础的应用软件的架构设计,得到一个功能强、性能好、适宜通信的架构。 二、名称 Fielding将他对互联网软件的架构原则,定名为REST,即Representational State Transfer的缩写。我对这个词组的翻译是”表现层状态转化”。 如果一个架构符合REST原则,就称它为RESTful架构。…

Continue Reading →

几种流行WebService框架性能对比

1、摘要 开发webservice应用程序中离不开框架的支持,当open-open网站列举的就有很多种,这对于开发者如何选择带来一定的疑惑。性能Webservice的关键要素,不同的框架性能上存在较大差异,而当前在官方网站、网络资料中可以方便的找到各自框架的介绍,但是很少有针对不同框架性能测试数据。本文选择了比较流行几个框架: Apache Axis1、Apache Axis2、Codehaus XFire、Apache CXF、Apache Wink、Jboss  RESTEasy、sun JAX-WS(最简单、方便)、阿里巴巴  Dubbo(除外)等,采用java作为测试用例,通过本机和远程两种进行测试方式,对这几种框架进行了性能测试,并对测试结果分析和性能比较,最后并对性能优异的框架进行了推荐。 目前三种主流的web服务实现方法: REST(新型):表象化状态转变 (软件架构风格)RESTEasy、Wink、CXF、Axis2……. SOAP(比较成熟):简单对象访问协议  Xfire、Axis2、CXF、Axis1 XML-RPC(淘汰):远程过程调用协议(慢慢被soap 所取代) 2、框架介绍 2.1 Apache Axis1 Axis本质上就是一个SOAP引擎(Apache Axis is an implementation of the SOAP),提供创建服务器端、客户端和网关SOAP操作的基本框架。但Axis并不完全是一个SOAP引擎,它还包括: l  是一个独立的SOAP服务器。 l  是一个嵌入Servlet引擎(例如Tomcat)的服务器。 l  支持WSDL。 l  提供转化WSDL为Java类的工具。 l  提供例子程序。 l  提供TCP/IP数据包监视工具。 2.2 Apache…

Continue Reading →

浅析RPC与WebService

现在非常火的RPC技术以SpringCloud和Dubbo为主流,但是如果做接口调用,还是逃不了要用一些较传统的技术。前几天在做接口调用时恰巧用到了WebService的相关技术。 1. RPC相关基础 1.1 什么是RPC —-| RPC(Remote Procedure Call),远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。(来自百度百科) —-| RPC允许程序调用另一个地址空间(通常是共享网络的另一台机器上)的过程或函数,而不需要显式编码这个远程调用的细节。 1.2 RPC的特点 从上面的概念中,能大概总结出RPC的基本特点如下: 通过网络传输的 跨终端、跨平台的 基于请求-响应的 只调用过程,不需关注细节 1.3 RPC的基本原理…

Continue Reading →

解决浏览器与服务器请求url长度限制

一、前言 Http中get与post本身是没有受到长度限制的,受到限制是浏览器与服务器对url长度限制。具体说明请阅读我的零一篇文章《关于 HTTP GET/POST 请求参数长度最大值的一个理解误区》。 二、概述 1、服务器限制 我目前使用的服务器一般是tomcat+nginx,它们都是通过控制http请求头的长度来进行限制 的,nginx的配置参数为large_client_header_buffers,tomcat的请求配置参数为 maxHttpHeaderSize,都是可以自己去进行设置。 2、浏览器限制 浏览器的限制:每种浏览器也会对url的长度有所限制, 下面是几种常见浏览器的url长度限制:(单位:字符) IE : 2803 Firefox:65536 Chrome:8182 Safari:80000 Opera:190000…

Continue Reading →

关于 HTTP GET/POST 请求参数长度最大值的一个理解误区

1. Get方法长度限制 Http Get方法提交的数据大小长度并没有限制,HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。 如:IE对URL长度的限制是2083字节(2K+35)。 下面就是对各种浏览器和服务器的最大处理能力做一些说明. Microsoft Internet Explorer (Browser) IE浏览器对URL的最大限制为2083个字符,如果超过这个数字,提交按钮没有任何反应。 Firefox (Browser) 对于Firefox浏览器URL的长度限制为65,536个字符。 Safari (Browser) URL最大长度限制为 80,000个字符。 Opera (Browser)…

Continue Reading →

Http状态码

HTTP状态码分类 HTTP状态码由三个十进制数字组成,第一个十进制数字定义了状态码的类型,后两个数字没有分类的作用。HTTP状态码共分为5种类型: HTTP状态码分类 分类 分类描述 1** 信息,服务器收到请求,需要请求者继续执行操作 2** 成功,操作被成功接收并处理 3** 重定向,需要进一步的操作以完成请求 4** 客户端错误,请求包含语法错误或无法完成请求 5** 服务器错误,服务器在处理请求的过程中发生了错误 HTTP状态码列表: HTTP状态码列表 状态码    …

Continue Reading →

Rest与RestfulAPI最佳实践

我经常会面试一些做PHP的开发者,让我很奇怪的是,10个人总有8个多不知道什么是REST服务,甚至是没有听说过。但RESTFul API已经是现在互联网里对外开放接口的主流模式,可参考: 豆瓣API https://developers.douban.com/wiki/?title=api_v2 GitHub https://developer.github.com/v3/ 数一数年限,据我接触REST到现在也差不多有8年左右了。可能大家现在对从JavaScript客户端直接访问服务器API这种模式非常的习以为常,但在8年前,Web并不是现在这个样子的。要说REST,我们先来看看在REST流行之前Web客户端是如何访问服务器接口的。 早期在移动端没有流行之前,Web API的概念还非常的弱,当时是网站盛行的年代,基本遵循着后台-前端的模型。后台产生数据,然后通过“模板”的形式将数据绑定到前端HTML代码里(渲染)。如下图所示: 那么这里就有一个“域”的概念,JavaScript只能访问同一个域的服务器。比如我们将一个站点部署在A这个域名www.a.com下,那么这个站点的前端JavaScript只能访问域名为www.a.com的服务端。如果我们需要访问非A站点的其他“服务”怎么办?看看下图: 在当时通用的做法是使用SOAP,Simple Object Access Protocol,简单对象协议,它使用XML作为数据的描述。我们看看使用SOAP的解决方案: JavaScript是不能直接访问SOAP服务的,需要首先访问自己的网站后台,再有网站后台访问SOAP服务。而且不同语言的网站后台,方位SOAP服务都需要有首先生成自己特定语言的“代理类”,Java有Java的、C#有C#的,这相当的繁琐与不好理解。这个时候我们的思考点来了,网站的后台对我来说意义是什么? 我为什么不能直接访问服务?为什么我不能把网站里的业务代码也提取成服务,最后变成以下的理想情况: 网站的后台几乎是个“壳子”,只负责网站本身的HTML页面、CSS、JavaScript文件等静态页面。而业务逻辑,交给服务来提供就好了。这样做的最大的好处是,业务变得独立了,可以被多个“网站”来共享访问了。有没有觉得挺熟悉?这个模式就是现在VUE、AngularJS等框架做的单页面应用程序。但是,在当时这种模式并不流行。我在很多年前就尝试这样的思维来构建Web,但是由于没有现在VUE、AngularJS等强大的SPA框架支持,效果并不好。但,我相信这种简洁的模式是Web的未来。我一向崇尚简洁,当年丢掉Flex、Silverlight、ASP.Net WebForm,独独选择JavaScript就是因为其他几个封装太多。 很多人认为模板引擎就是很好的前后端分离,可我不这么认为,SPA才是真正的前后端分离,他们之间使用Ajax通信,前端就是最简单的HTML,前端开发人员一行服务器代码都看不到,这才是真的和语言无关,才是真正的前后端分离。 我来分析下,为什么以前SPA应用并不流行。 第一,一个是网站的思维根深蒂固; 第二,就是出于性能考虑,单页面频繁的Ajax请求将给服务器造成巨大的压力。而网站网页的静态化技术已经是非常的成熟的了,所以SPA这个概念在早期并不怎么提倡。而且SPA也有自己的局限性,并不是所有的网站都适合用SPA来代替。但现在服务器缓存技术的发展(特别是Memcache和Redis出现后)大大的解决了服务器支持SPA负载过高的问题,甚至比传统的网页静态化技术更加的简单易用;再加上VUE、AngularJS强大的能力,这才使SPA真正的流行起来。…

Continue Reading →