记录－交流－Web开发知识分享
设计HTTP和RESTful API可能很棘手，因为没有官方和强制标准。基本上，有许多方法可以实现API，但其中一些已在实践中得到证实，并且已被widley采用。这篇文章介绍了构建HTTP和RESTful API的最佳实践。我们将讨论URL结构，HTTP方法，创建和更新资源，设计关系，有效负载格式，分页，版本控制等等。
我完全重写了这篇文章。我重新访问并扩展了现有的部分并添加了许多新的部分：HTTP方法和状态代码的新概述，PATCH，清除PUT和POST的语义，data字段，设计关系，REST与RPC风格的API，可演化性，版本控制方法，基于键集分页，JSON：API，JSON：API启发的有效负载格式。…
大多数现代Web应用程序都公开了客户端可用于与应用程序交互的API。精心设计的Web API应旨在支持：
本指南介绍了在设计Web API时应考虑的问题。
2000年，Roy Fielding提出了Representational State Transfer（REST）作为设计Web服务的架构方法。REST是一种用于构建基于超媒体的分布式系统的架构风格。REST独立于任何底层协议，不一定与HTTP绑定。但是，大多数常见的REST实现都使用HTTP作为应用程序协议，本指南重点介绍如何为HTTP设计REST API。
REST over HTTP的主要优点是它使用开放标准，并且不会将API或客户端应用程序的实现绑定到任何特定实现。例如，REST Web服务可以用ASP.NET编写，客户端应用程序可以使用任何可以生成HTTP请求和解析HTTP响应的语言或工具集。
以下是使用HTTP的RESTful API的一些主要设计原则：
RESTful 是目前最流行的 API 设计规范，用于 Web 数据接口的设计。
它的大原则容易把握，但是细节不容易做对。本文总结 RESTful 的设计细节，介绍如何设计出易于理解和使用的 API。
RESTful 的核心思想就是，客户端发出的数据操作指令都是"动词 + 宾语"的结构。比如，GET /articles这个命令，GET是动词，/articles是宾语。
动词通常就是五种 HTTP 方法，对应 CRUD 操作。
- GET：读取（Read）
- POST：新建（Create）
- PUT：更新（Update）
- PATCH：更新（Update），通常是部分更新
- DELETE：删除（Delete）
根据 HTTP 规范，动词一律大写。
有一段时间没怎么写文章了，今天提笔写一篇自己对 API 设计的思考。首先，为什么写这个话题呢？其一，我阅读了《阿里研究员谷朴：API 设计最佳实践的思考》一文后受益良多，前两天并转载了这篇文章也引发了广大读者的兴趣，我觉得我应该把我自己的思考整理成文与大家一起分享与碰撞。其二，我觉得我针对这个话题，可以半个小时之内搞定，争取在 1 点前关灯睡觉，哈哈。
现在，我们来一起探讨 API 的设计之道。我会抛出几个观点，欢迎探讨。
通常情况下，规范就是大家约定俗成的标准，如果大家都遵守这套标准，那么自然沟通成本大大降低。例如，大家都希望从阿里的规范上面学习，在自己的业务中也定义几个领域模型：VO、BO、DO、DTO。其中，DO（Data Object）与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。 而 DTO（Data Transfer Object）是远程调用对象，它是 RPC 服务提供的领域模型。对于 BO（Business Object），它是业务逻辑层封装业务逻辑的对象，一般情况下，它是聚合了多个数据源的复合对象。那么，VO（View Object） 通常是请求处理层传输的对象，它通过 Spring 框架的转换后，往往是一个 JSON 对象。…
越来越多的人开始意识到，网站即软件，而且是一种新型的软件。
这种"互联网软件"采用客户端/服务器模式，建立在分布式体系上，通过互联网通信，具有高延时（high latency）、高并发等特点。…
【编者的话】作者根据自己的微服务经验，提出REST并不是微服务的唯一通信机制，从而介绍了微服务的几种通信机制，包括REST、管道以及基于异步消息传递。同时，作者提出了在不同的场景下可以使用不同的通信机制。
在我接触微服务的这段时间，大部分关于如何安装部署微服务的线上样例或文章都一致认为REST是微服务之间通信的唯一方式。因此，你可能理所当然地认为REST就是微服务的一种标准，并且是设计与实现微服务系统一种方式。然而，并非如此。…
来源：http://www.oschina.net/translate/best-practices-for-a-pragmatic-restful-api
数据模型已经稳定，接下来你可能需要为web（网站）应用创建一个公开的API（应用程序编程接口）。需要认识到这样一个问题：一旦API发布后，就很难对它做很大的改动并且保持像先前一样的正确性。现在，网络上有很多关于API设计的思路。但是在全部案例中没有一种被广泛采纳的标准，有很多的选择：你接受什么样的格式？如何认证？API应该被版本化吗？
在为SupportFu（一个轻量级的Zendesk替换实现）设计API时，对于这些问题我尽量得出一些务实的答案。我的目标是设计这样一个API，它容易使用和采纳，足够灵活去为我们用户接口去埋单。…
本文是“深入探索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是怎么得来的。…
客户端
client.php
<?php
//PUT
$curl_handle = curl_init ();…
近期评论