1. 什么是REST
REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。" 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。
REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。
2. 理解RESTful
要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。 下面我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。
统一资源接口
资源的表述
资源的链接
状态的转移
2. 1 资源与URI
REST全称是表述性状态转移，那究竟指的是什么的表述? 其实指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子：
某用户的手机号码
某用户的个人信息
最多用户订购的GPRS套餐
两个产品之间的依赖关系
某用户可以办理的优惠套餐
某手机号码的潜在价值
要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。
URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。这里以github网站为例，给出一些还算不错的URI：
/git/git/blob/master/block-sha1/sha1.h
/git/git/commit/e3af72cdafab5993d18fae056f87e1d
/git/git/pulls
/git/git/pulls?state=closed
/git/git/compare/master…next
下面让我们来看看URI设计上的一些技巧:
使用_或-来让URI可读性更好
曾经Web上的URI都是冰冷的数字或者无意义的字符串，但现在越来越多的网站使用_或-来分隔一些单词，让URI看上去更为人性化。 例如国内比较出名的开源中国社区，它上面的新闻地址就采用这种风格， 如http://www.oschina.net/news/38119/oschina-translate-reward-plan。
使用/来表示资源的层级关系
例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d就表示了一个多级的资源， 指的是git用户的git项目的某次提交记录，又例如/orders/2012/10可以用来表示2012年10月的订单记录。
使用?用来过滤资源
很多人只是把?简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把?用于对资源的过滤， 例如/git/git/pulls用来表示git项目的所有推入请求，而/pulls?state=closed用来表示git项目中已经关闭的推入请求， 这种URL通常对应的是一些特定条件的查询结果或算法运算结果。
,或;可以用来表示同级资源的关系
有时候我们需要表示同级资源的关系时，可以使用,或;来进行分割。例如哪天github可以比较某个文件在随意两次提交记录之间的差异，或许可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d;bd63e61bdf38e872ddcc16e4febca作为URI。 不过，现在github是使用…来做这个事情的，例如/git/git/compare/master…next。
2. 2 统一资源接口
RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。
如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的， 无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次， 结果总是一样的，后面的请求并不会产生比第一次更多的影响。
下面列出了GET，DELETE，PUT和POST的典型用法:
安全且幂等
变更时获取表示（缓存）
200（OK） - 表示已在响应中发出
204（无内容） - 资源有空表示
301（Moved Permanently） - 资源的URI已被更新
303（See Other） - 其他（如，负载均衡）
304（not modified）- 资源未更改（缓存）
400 （bad request）- 指代坏请求（如，参数错误）
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前无法处理请求
不安全且不幂等
使用服务端管理的（自动产生）的实例号创建资源
创建子资源
部分更新资源
如果没有被修改，则不过更新资源（乐观锁）
200（OK）- 如果现有资源已被更改
201（created）- 如果新资源被创建
202（accepted）- 已接受处理请求但尚未完成（异步处理）
301（Moved Permanently）- 资源的URI被更新
303（See Other）- 其他（如，负载均衡）
400（bad request）- 指代坏请求
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
409 （conflict）- 通用冲突
412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务当前无法处理请求
不安全但幂等
用客户端管理的实例号创建一个资源
通过替换的方式更新资源
如果未被修改，则更新资源（乐观锁）
200 （OK）- 如果已存在资源被更改
201 （created）- 如果新资源被创建
301（Moved Permanently）- 资源的URI已更改
303 （See Other）- 其他（如，负载均衡）
400 （bad request）- 指代坏请求
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
409 （conflict）- 通用冲突
412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务当前无法处理请求
不安全但幂等
200 （OK）- 资源已被删除
301 （Moved Permanently）- 资源的URI已更改
303 （See Other）- 其他，如负载均衡
400 （bad request）- 指代坏请求
404 （not found）- 资源不存在
409 （conflict）- 通用冲突
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前无法处理请求
下面我们来看一些实践中常见的问题:
POST和PUT用于创建资源时有什么区别?
POST和PUT在创建资源的区别在于，所创建的资源的名称(URI)是否由客户端决定。 例如为我的博文增加一个java的分类，生成的路径就是分类名/categories/java，那么就可以采用PUT方法。不过很多人直接把POST、GET、PUT、DELETE直接对应上CRUD，例如在一个典型的rails实现的RESTful应用中就是这么做的。 我认为，这是因为rails默认使用服务端生成的ID作为URI的缘故，而不少人就是通过rails实践REST的，所以很容易造成这种误解。
客户端不一定都支持这些HTTP方法吧?
的确有这种情况，特别是一些比较古老的基于浏览器的客户端，只能支持GET和POST两种方法。 在实践上，客户端和服务端都可能需要做一些妥协。例如rails框架就支持通过隐藏参数_method=DELETE来传递真实的请求方法， 而像Backbone这样的客户端MVC框架则允许传递_method传输和设置X-HTTP-Method-Override头来规避这个问题。
统一接口是否意味着不能扩展带特殊语义的方法?
统一接口并不阻止你扩展方法，只要方法对资源的操作有着具体的、可识别的语义即可，并能够保持整个接口的统一性。 像WebDAV就对HTTP方法进行了扩展，增加了LOCK、UPLOCK等方法。而github的API则支持使用PATCH方法来进行issue的更新，例如:
PATCH /repos/:owner/:repo/issues/:number
不过，需要注意的是，像PATCH这种不是HTTP标准方法的，服务端需要考虑客户端是否能够支持的问题。
统一资源接口对URI有什么指导意义?
统一资源接口要求使用标准的HTTP方法对资源进行操作，所以URI只应该来表示资源的名称，而不应该包括资源的操作。 通俗来说，URI不应该使用动作来描述。例如，下面是一些不符合统一接口要求的URI:
GET /getUser/1
POST /createUser
PUT /updateUser/1
DELETE /deleteUser/1
如果GET请求增加计数器，这是否违反安全性?
安全性不代表请求不产生副作用，例如像很多API开发平台，都对请求流量做限制。像github，就会限制没有认证的请求每小时只能请求60次。 但客户端不是为了追求副作用而发出这些GET或HEAD请求的，产生副作用是服务端"自作主张"的。 另外，服务端在设计时，也不应该让副作用太大，因为客户端认为这些请求是不会产生副作用的。
直接忽视缓存可取吗?
即使你按各个动词的原本意图来使用它们，你仍可以轻易禁止缓存机制。 最简单的做法就是在你的HTTP响应里增加这样一个报头： Cache-control: no-cache。 但是，同时你也对失去了高效的缓存与再验证的支持(使用Etag等机制)。 对于客户端来说，在为一个REST式服务实现程序客户端时，也应该充分利用现有的缓存机制，以免每次都重新获取表示。
响应代码的处理有必要吗?
HTTP的响应代码可用于应付不同场合，正确使用这些状态代码意味着客户端与服务器可以在一个具备较丰富语义的层次上进行沟通。 例如，201（"Created"）响应代码表明已经创建了一个新的资源，其URI在Location响应报头里。 假如你不利用HTTP状态代码丰富的应用语义，那么你将错失提高重用性、增强互操作性和提升松耦合性的机会。 如果这些所谓的RESTful应用必须通过响应实体才能给出错误信息，那么SOAP就是这样的了，它就能够满足了。
2. 3 资源的表述
上面提到，客户端通过HTTP方法可以获取资源，是吧? 不，确切的说，客户端获取的只是资源的表述而已。 资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。 例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。 资源的表述包括数据和描述数据的元数据，例如，HTTP头"Content-Type" 就是这样一个元数据属性。
那么客户端如何知道服务端提供哪种表述形式呢?
答案是可以通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。
以github为例，请求某组织资源的json格式的表述形式:
　　假如github也能够支持xml格式的表述格式，那么结果就是这样的:
　　下面我们来看一些实践上常见的设计:
在URI里边带上版本号
有些API在URI里边带上版本号，例如:
如果我们把版本号理解成资源的不同表述形式的话，就应该只是用一个URL，并通过Accept头部来区分，还是以github为例，它的Accept的完整格式是:application/vnd.github[.version].param[+json]
对于v3版本的话，就是Accept: application/vnd.github.v3。对于上面的例子，同理可以使用使用下面的头部:
Accept: vnd.example-com.foo+ version=1.0
Accept: vnd.example-com.foo+ version=1.2
Accept: vnd.example-com.foo+ version=2.0
使用URI后缀来区分表述格式
像rails框架，就支持使用/users.xml或/users.json来区分不同的格式。 这样的方式对于客户端来说，无疑是更为直观，但混淆了资源的名称和资源的表述形式。 我个人认为，还是应该优先使用内容协商来区分表述格式。
如何处理不支持的表述格式
当服务器不支持所请求的表述格式，那么应该怎么办？若服务器不支持，它应该返回一个HTTP 406响应，表示拒绝处理该请求。下面以github为例，展示了一个请求XML表述资源的结果：
　　2. 4 资源的链接
我们知道REST是使用标准的HTTP方法来操作资源的，但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。 这种反模式忽略了一个核心概念："超媒体即应用状态引擎（hypermedia as the engine of application state）"。 超媒体是什么? 当你浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：把一个个把资源链接起来.
要达到这个目的，就要求在表述格式里边加入链接来引导客户端。在《RESTful Web Services》一书中，作者把这种具有链接的特性成为连通性。下面我们具体来看一些例子。
下面展示的是github获取某个组织下的项目列表的请求，可以看到在响应头里边增加Link头告诉客户端怎么访问下一页和最后一页的记录。 而在响应体里边，用url来链接项目所有者和项目地址。
　　又例如下面这个例子，创建订单后通过链接引导客户端如何去付款。
上面的例子展示了如何使用超媒体来增强资源的连通性。很多人在设计RESTful架构时，使用很多时间来寻找漂亮的URI，而忽略了超媒体。所以，应该多花一些时间来给资源的表述提供链接，而不是专注于"资源的CRUD"。
2. 5 状态的转移
有了上面的铺垫，再讨论REST里边的状态转移就会很容易理解了。 不过，我们先来讨论一下REST原则中的无状态通信原则。初看一下，好像自相矛盾了，既然无状态，何来状态转移一说?
其实，这里说的无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。
2. 5.1 应用状态与资源状态
实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。 客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。 服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。
这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。 在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。
但有时候我们会做出违反无状态通信原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。 这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。 当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。
2. 5.2 应用状态的转移
状态转移到这里已经很好理解了， "会话"状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。 这些类似"下一页"之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。
现在广东XXX版本、XXX等项目中均使用传统的RPC、SOAP方式的Web服务，而移动南方基地XXXX项目的后台， 虽然采用了JSON格式进行交互，但还是属于RPC风格的。本文从资源的定义、获取、表述、关联、状态变迁等角度， 试图快速理解RESTful架构背后的概念。RESTful架构与传统的RPC、SOAP等方式在理念上有很大的不同，希望本文能对各位理解REST有所帮助。
记住登录状态
重复输入密码RestKit ,一个用于更好支持RESTful风格服务器接口的iOS库
byte：表示操作类型，从而分辨操作
但是4种操作服务器返回的内容是不一样的
所以返回的消息定义
byte&：操作类型
byte：&操作结果
char[126]：返回信息的buf，不同的返回信息组在一起扔到buf中返回，由客户端自行根据协议解析，
大家觉得第二种方式
13:09&&&[]
本文介绍小生自己编写的一个服务器软件，项目的主页是sourceforge.net/projects/mchttpd/。 基本信息： name: MC_HTTPDauthor: 颜文泽(robin)Revision: 0.9 注：程序为不稳定版本，不建议正式使用。如果有任何问题、建议和bug都请联系
13:42&&&[]
是这样的，我们有20多台服务区，上面部署了web应用，现在我们每次看服务器都要远程连到服务器看服务器的运行情况，现在我想做个页面，能用什么方式测试服务器挂没挂？我自己做了一个html页面，就是写了很多链接，用get方式带了用户名密码去登陆，但这样会打开很多页面，也不美观，敢问各位大侠有没有其他
-12:53&&&[]
是否有攻击现象，比如1秒钟有3条尝试登录记录，那就遭了。
解决办法：修改远程登录端口登录方式和修改数据库端口号。
看看，凑个热闹，哈哈
&&自己也很吐血，去看了下系统日志&是一个不停的攻击数据库端口！&很想改下数据库端口，但是服务器站点有点多美敢动呀
-11:39&&&[]
我用VB写了一个邮件发送服务器，在我的环境中是可以的！我的机器是2003的，但是放到XP或者别的里面就用不了了！我写的这个是调用API的，请问改怎么办？或者有没有更好的解决方案！谢谢！
回复讨论(解决方案)
WIN2003本身就是服务器版，在其它系统如XP、VISTA下，重新调试，编译
-14:03&&&[]
本帖最后由 VisualEleven 于
09:24:22 编辑
我还在学习，所以用的是很老的VC6。然后改了一个程序。嗯主要问题是dwBufferCount也就是第三个参数，就是ldwBuffer这个的数量。然后可以运行，但是出现了乱码。也就是wsabuf[1
-12:01&&&[]
有2台服务器A&B
在我电脑上可以连接A和B
服务器A&可以连接到&B
服务器B　连接不上A
(这里连接是指&telnet，数据库远程连接等)
放完假就出现这个问题了，是什么原因呢?
回复讨论(解决方案)
既然你说不久之前还是可以访问的
-18:22&&&[]
不能是，用户登录以后，固定的周期内去服务端取消息？
这是最普通的轮询，ajax定时去取就行
这样的周期设置短了，对服务器压力大，设置长了，实时性又不好
到目前为止，我还没用过任何一个java框架
java&socket的话，你有框架推荐吗
-16:33&&&[]
& & & & 在【一步一个脚印】Tomcat+MySQL为自己的APP打造服务器（1）服务器环境搭建中我们搭建了完整的服务器开发环境，但是之前的两篇讨论Servlet 的文章并没有用到 MySQL 数据库，因为仅有的登录验证业务也是模拟的。然而在实际业务中
02:57&&&[]
不同应用指定不同的、用于标识SessionID&的Cookie名称。
另一个项目的连接失效就是发送请求没有响应，撇开返回登录页面（个人浅见：返回登陆页面是对请求的资源进行访问控制管理，请求必须登录在web服务器存在session）。你说的方案我在理解理解，现在不敢评论，我刚刚进入软件公司
-19:28&&&[]
/bin/& ---&& mysql的data目录（真的需要吗，我直接就在根目录下操作的）
二、导入数据库（目标服务器） 1、首先建空数据库 mysql&
2、导入数据库 （1）选择数据库 mysql&use abc
20:05&&&[]
用netbeans写了2个服务器web&service，想用其中一个调用另外一个服务器，但是不知道怎么调用？
回复讨论(解决方案)
一个调另一个时，其中一个肯定被作为客户端处理了，给里面添加客户端调用程序试试
url地址栏From提交
-15:41&&&[]从App角度看API (RESTful) 设计 - 简书
从App角度看API (RESTful) 设计
要API，不要做外星人 (图片来自网络)
首发：/p/ace1428888ca
做了10多年的桌面和逻辑模块的开发，两年前才开始接触互联网这一块，说起来对RESTful API是没有太多经验的。公司app搭建之初，前后端通力合作，期间同不少后端同事就API的设计都有过沟通交流；到现在app上线也要快满一年了，不久前进行了一次大改版，部分API也从v1升级到了v2，觉得有些经验，可以总结一下。
一. API设计的一些基本原则
API是自述的大多数我看的资料所写的Intuitive（直观的、直觉可理解的），也有些写Descriptive（描述性的），我将其命名为“自述”。一个API有自述性，也就是说看到API的URL，就知道这个API是要干嘛；且这个API的返回值中的字段，又能很好的解释其返回的内容。虽然API文档是不可或缺的，但是如果看到API的URL和API的返回值字段就知道这个API的功能作用，多好！（注：下文有实例）
API是完备的对于一组API，我们会要求其为最小完备集。对于一个API，个人觉得其同样有最小完备性。这里我主要是指在各种输入参数情况下，API的返回都应该是合理的、完全的。（实际工作中我发现为了满足各种不同的需求，有时候API的返回值中会插入一下冗余信息，因此我这里只提完备性。）（注：下文有实例）
API是抽象的在软件工程中，一直都有各式各样的Add a Layer of Indirection，即通过一层抽象，屏蔽掉具体的数据/实现/细节。使用领域和表现形式各异，其原理实则相同。API的设计同样适用。（注：下文有实例）
API是兼容及可扩展的一个API可能需要同时服务于不同的平台：Web、iOS、Android等，也可能需要服务同一个平台的不同版本。虽然可以通过创建不同的API版本（Versioning）达到相同的目的，但是如果同一个API就能做到，岂不更好？（注：下文有实例）
其它另有很多重要特性，比如安全性、Tracking等，但是我个人觉得和我想表达的主题还是有差异。如需更多了解，请参看文章最后的链接。
二. 我亲历、验证了的API设计Tip
1. 使用 JSON Object (Dictionary/HashMap)
JSON格式简美，是现在流行的通信格式。上一句是废话，其实我想说的是，相对于Array，使用Object （Obj-C/Swift中可与Dictionary互转，Java中可与HashMap互转） 能够让API有更大的腾挪空间。
比如有个搜索视频关键字，返回视频列表的API，要求能够让客户端对视频列表进行分页浏览。最开始设计返回的是JSON Array，在HTTP header中带入总页数供客户端进行分页处理。
这个API的设计简明直白：你需要列表，我返回Array。因此服役了不短的时间。后来需求变了，要求在用户搜索特定关键字或者出现特定视频的时候，在页面上加入特殊的Label。然后，然后...不得不重新设计了v2版本的API。为了继续服务老版app，后台需要维护两套API。烦！
若最开始这个API就设计成JSON Object，则有好处如下：
总页数不必带在HTTP header中，整个API的信息都集中在Object内。即是我上面提到的“API的自述性”
对于新的需求，增加一对Key-Value即可，老版app和新版app采用同一个API，不需要额外的逻辑去维护两套API。即是我上面提到的“API的兼容和扩展性”
2. API不要返回后台数据库的index（如自增长ID）
前端对后台资源进行引用时，常需要一个唯一标识，比如xxID之类。当时后台小伙极力说服我使用数据库中的自增长ID，被我否决了。一般而言，生成一个全局唯一的UUID或者标识性String都是不错的选择。
前些时则发生了另外一件事，很能说明些问题。有个资源文件比较庞大，我采取了如下的使用和更新策略：
app内用本地文件的方式预存一份数据 (version=1)
当app内需要用到这个数据时，先查找缓存，再查找本地文件，这样可以保证以最快的速度获取到数据进行展示
同时，app走API向后台获取这个文件的新版本（带入version=1的参数）
若数据没有更新的版本，后台返回空
若数据有新版本，则下载并缓存
这种方法对数据量大、更新不频繁、后台对数据容忍性大的API非常适用。可惜上线前突然bug了。最后查找原因，发现是因为之前都在测试服务器上测试，本地文件保存的数据中含有后台数据库的自增长ID。上线前在production服务器上一跑，查无此人。
上面说了一个不使用后台数据库自增长ID的具体例子。也即是前面提到的“API的抽象性”。
3. API获取资源要精准完备
由于业务逻辑的需要，常规的API设计可能会有疏漏时，需要根据情况仔细斟酌。
比如有个网站搜集了过去一年和未来半年全世界所有的公开课、讲座和会议信息，当用户进行浏览时，默认显示当前时间点以后的50条信息；当用户往下翻至第50条时，继续加载后50条；当用户往上翻至第一条并pull整个列表时，前向加载过去的50条信息。
初看起来这个API和前面提到的视频列表很相似，但是存在如下条件：
用户每次刷新时，都有可能有新的公开课、讲座或会议成为过去时，但是用户在连续刷新的过程中，应该尽量看到完整的（无缺失且不重复）的信息
同一时间可能有多个公开课同时开始
后台数据在不停添加，有可能在用户的某两次刷新间隔，就有了新的数据。
因此，传统的分页方式肯定是不行的。中间构思过以第一次浏览时间点作为基准的设计，也被找出了n多问题。
最终我们采用的是以UUID为基准的设计。
当用户第一次浏览时，会根据用户的访问时间点，对所有条目进行时间+自增长ID的二次排序，并返回前50条
当用户向下翻页时，提供最后一个条目的UUID作为参数，后台搜索到其时间和自增长ID，然后同样以时间+自增长ID作为过滤条件进行排序，并返回前50条
当用户向前翻页时，提供第一个条目的UUID作为参数，同上。
举这个例子，主要是想说设计API一定要仔细谨慎，使其具有完备性。但是，让人遗憾的是，这个API其实在某些情况下还是会有遗漏，对照前面的3个条件，你能发现问题吗？
4. API默认值的意义
iOS平台编程中，UIView类提供了hidden属性，用于隐藏此窗口。为何用hidden而不用shown呢？因为窗口默认是显示的，对应着属性的默认值NO(false)。这样的设定同样适用于API的设计。
比如app中采用统一的广告策略：使用webview加载广告页。但是广告页的展示和动画则可能有两种形式：
广告页有navigation bar (push进来或者包在navigation bar中被present出来)，并显示navigation title。
广告页被全屏present出来
绝大多数情况下，广告页都采用第一种方案展示，但是特殊的广告页可能会要求采用第二种方案展示(比例较低)。后台API提供广告URL，以及展示广告页的形式。
这个例子中，显示navigation bar的广告页就是默认情况，因为显示navigation bar的概率大。在我明了上面这段分析之前，API是这么设计的：
{ URL: "https://xxx", nav_title: "NOT Ads" }
这里，nav_title承担了双重责任：
如果nav_title不为空字符串，广告页显示navigation bar并设置navigation title。
否则，广告页采用全屏展示；
初看起来这样的设计好像也挺不错。但是由于nav_title的默认值（nil）并不对应广告页的默认展示形式（带navigation bar），可能无法应对新的需求变更。比如以后因为要加入新的展示形式而需要废弃掉nav_title、替换成别的字段时，会发现nav_title删不得。WHY？因为老版本的用户必须依赖于这个参数的非默认值，简直太糟糕了。至于如何设计这个API才算好，那就见仁见智了。
5. 全局HTTP header
全局HTTP头很金贵，因为一旦设置，则所有的API都会带上，增加数据量+消耗流量。一般来说，用户信息、平台和版本信息等都是不可缺少的，更多的可以参看我后面给出的链接。我这里要提醒的是，现在的App设计中，总难保不打开一些web页面，最好记得在webview的HTTP header中做同样的处理哟~
6. 常量Key
上文提到API返回最好是一个JSON Object (Dictionary/HashMap)，便于扩展。本节标题里说的Key，就是键值对（key-value）中的key，而常量就是我们通常意义上的const。也就是说，我们用于通信的API接口，其key最好能写成const。
比如app请求后台的广告业务数据，参数是placementID，后台根据配置，获取该placementID所对应的广告展示类型adType，然后把数据adData返回给app。
一种意见是用placementID做为key，客户端根据placementID来获取广告，感觉十分直接。结构如下：
{"ads" : {placementID: adData}}
但是app端在这里需要额外的判断adData所隐含的展示类型，认为不妥
另一个种意见是以广告的展示类型adType作为key，app端根据UI的展示方式获取数据，贴近实现。结构如下：
{"ads" : {adType: adData}}
但是这种方法一是丢掉了placementID的信息，扩展性上存在问题（比如一次性请求多个placement的广告时）；二是广告的展示类型可能会随业务变化，作为key时同样有兼容性的问题。
但是按照本节的标题所建议的设计方式就不存在这方面的问题了。结构如下：
{"ads" :　[　 {"ad_placement_id": placementID,　"ad_type": adType,　"ad_data": adData},　 ...　]}
在上面最后的实现中，所有的key都是const，即"ads", "ad_placement_id","ad_type"和"ad_data"，整个API都很容易扩展，保持良好的兼容性。
三. 别人总结的经验
网上也有一些经验总结，可以参考：
（有中文翻译）
（QT的API设计原则--Restful API和Lib API大同小异）
（InfoQ的一个总结）}