蜗牛的专栏

RESTful API 设计最佳实践（3）一、无状态和有状态无状态服务，是REST风格服务的核心约束。无状态指的是：处理请求所需要的状态信息都放在请求里面（如，放在URI路径、查询参数、body以及Header中等），而不是存放在服务器端。服务器端从请求中获取到相关状态信息，对请求进行处理之后，将需要返回的状态信息放在诸如body、header中，返回给客户端。无状态服务，是不要求请求有先后次序的。

一、数据总线-分层模型整个流程像是“污水处理”过程：服务层（service层）接到最初的污水之后，将里面的一些物质初步整理出来（提取出参数，转化格式等），然后放入一个包（event-package)中，标注好这个包的ID以及它在service层的处理结果，然后扔回到水管中；包沿水管流到下一层（core业务逻辑层）进行处理，core业务逻辑层拿到service层处理后的数据，根据ID对应的业务规则进行处理，将处理结果

一、中间件模型中间建模型是插件模型的一种改进版。上次提高插件模型中，核心业务逻辑处理模块并不是一个真正的“纯函数”，因为它里面存在写操作。中间件模型正是将这些写操作剥离出来，放在一个中间件中。中间件只负责执行事务（包括数据库操作，rmi/rpc/http远程调用，内存数据操作等），不理解业务，比如它只负责SQL语句的执行，而不知道SQL是如何组织的，也不知道SQL的内容。二、模块说明因为大多数模块和

一、模型图该模型是自己摸索出来的一种web服务设计模型，整个围绕核心业务逻辑处理模块进行。在这个模型中，core业务逻辑处理中心处理负责执行所有逻辑处理流程，该模块所需要的所有副作用操作都以“插件”的形式从参数中传入。而所谓的“插件”，其实就是一些处理副作用读写的函数。二、模块说明service模块提供网络服务，根据具体使用的技术，对客户端来的请求进行路由分发，提取出请求参数，对参数进行解密、格式转

一、模型图“service/logic/dao/db”是一种非常常见的分层架构，从代码层次上看，同一层次代码可以放在同一个package，或以…Logic, …Dao等类名来区分；在程序实现处理过程中，都严格遵循上层调用下层函数的方式进行，不会出现跨层、反向调用，一直调用到最底层。二、优点在使用过程中，感觉到这种模型的好处就是比较简单，对于每一个请求，都是一层一层代码往下写，如果下层代码可复用，就直

现在的程序设计哲学中，“数据>函数>宏”是一种流行趋势，即数据优于函数，函数优于宏。宏排在末位，不足为奇。对于宏的使用，有一种指导方法是：不到不得已的时候，不要使用宏。因此，我们在此只讨论“数据>函数”。一、“数据>函数”的几个例子1. REST风格服务架构近两年，REST流行，人们纷纷抛弃RPC，转向REST。众所周知，REST风格服务的抽象工具是资源，即数据；而RPC服务的

前面几篇文章介绍了一些RESTful API设计方面的参考规范，这篇文章我们来看几个“不良”的例子，并以个人的实践总结为这一系列做个结尾。欢迎大家评论交流。一、几个“不良”示例 1. 查询当前活动状态** 请求：**GET /activity/query?method=status&game=PDK&type=aAccept:json ** 应答：**{:status-code 200

RESTful API 设计最佳实践（7）本篇博客将侧重介绍在RESTful API设计中，消息头HEADER和消息体body相关的东西。URL只是RESTful API设计的主要一部分，要实现REST的统一接口，HTTP协议中的其他部分也不可或缺。关于统一接口，可查看我之前的博客。一、返回新建资源的URL使用POST新建的资源时，如果创建成功，则返回201状态码，，应该在返回的消息头HEADER的

RESTful API 设计最佳实践（6）在本文中，将重点介绍一些实际设计RESTful API的建议，这些API是基于HTTP协议设计的。这些建议是参考网上一些好的资料并结合自己实际经验做了更加细致的分析，个人觉得有不错的参考价值。一、两个简单的例子1. 简单资源的CRUD GET /users - 获取用户列表 GET /users/:id - 获取用户ID号为:

RESTful API 设计最佳实践（5）在上篇文章中，主要介绍了Roy Fielding论文中，关于统一接口的四个约束，并对其中资源定义相关部分阐述了自己的一些观点。本章节主要介绍一下我们现实中最为常见的，也是REST统一接口的最佳实践者——HTTP规范，着重介绍设计RESTful API时，对于HTTP方法选择，以及REST服务实现过程中需要注意的点。

RESTful API 设计最佳实践（4）目前，对于RESTful API设计并没有非常严格的标准，但一定要尽量满足以下需求：（1）使用WEB标准，如满足HTTP协议规范（2）对开发者友好，并且可以通过浏览器、curl等简单工具进行调用。（3）简单、易用、一致。（4）高效。这一章节，我想先介绍一下REST中统一接口相关理论知识。

RESTful API 设计最佳实践（2）常见的分布式应用架构风格有三种： （1）分布式对象（Distributed Objects） 架构实例：CORBA/RMI/EJB/DCOM/.NET Remoting等。 （2）远程过程调用（RPC） 架构实例：SOAP/XML-RPC/Hessian/Flash AMF/DWR等。 （3）表述性状态转移（REST） 架构实例：HT

RESTful API 设计最佳实践（1）——在Roy Thomas Fielding看来，这可能（kending）不是真正的REST，但也将是一个因REST所带来的好的实践。一、Representational State Transfer (REST)概述1. 相关概念（1）资源： rest对于资源的定义基于一个简单的前提：标识符的改变应该尽可能少的发生，将一个资源定义为创作者想要标识的语义，而

一、模板方法模式的定义 在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。从定义可以看出，模板方法的本质是：封装算法。类图结构： 其中，templateMethod会调用抽象类中定义的一些抽象方法，或者已经实现（默认的具体实现）的方法（称之为“钩子”），子类（实现类）需要实现父类中的抽象方法，或者覆盖父类中已实现