我为何反对RESTful

我反对RESTful

并非说RESTful彻底错误，只是不同意它的理念。

我的观点，不喜勿喷！学识有限，浅谈辄止！

首先，看个小程序。对于下面这个类，咱们如今指望pid只读。

class User
{
    private String name;//姓名
    private String pid;//身份证号
    ...

    public User(String newName,String newPid)
    {
        name = newName;
        pid = newPid;
    }
}

方法一：增长getter

public String getPid()
{
    return pid;
}

方法二：同时增长getter/setter

public void setPid(String newPid)
{
    throw new Exception("Sorry!不让改！");
}
public String getPid()
{
    return pid;
}

不知你们采用哪一种？？

再举个例子，若是你有一间房子，你永远不打算从南面走出去。那么，你是在南边装扇门并永远锁上，仍是干脆不在南墙上装门？

其实我想说的是————对于一个系统（或干脆就指一台服务器）而言，对外提供的应该是‘通过包装的有限服务’，而不能把全部资源全盘托出，让使用者自选操做。

HTTP做为网络协议，它的设计目标是处理静态资源（从最先的纯html页面，到后来普遍支持各类文件），随着web应用的需求愈来愈复杂，出现了动态网站，而动态资源仍然是由应用服务器生成静态资源经HTTP协议转发的。

原来的web服务器，直接基于OS和文件系统操做静态资源，于是使用GET/POST/DELETE/PUT来表示对资源的操做；而应用服务器，至关于前端逻辑与数据资源的中间件，对资源的处理是应用程序的工做，CRUD是接口内部实现中考虑的问题，应当保持在应用程序内部。

接口的设计应只考虑当前业务功能是什么（报名/下单/改签/..），一项具体的业务需求是一个短语或一句话，深层次已经包含了目标资源和对应操做，请求业务时无需再额外描述“增删改查”的概念。因为系统服务的包装性，资源不可直接外露，因此API中URI的实际做用应该是USI（Uniform Service Identifier）。

####RESTful的问题就在于，它是面向资源的，而不是面向服务的。

• 最现实的问题就是————对于任一个URI，开发者都要判断HttpMethod，对于不支持的动做都要返回一个405或自定义消息。这，难道不是一件很无聊的事情么？
• 最重要的问题仍是————上面说到的，系统应该严格控制对内部资源的访问，以服务的方式对外提供访问接口，主动屏蔽不支持的操做，而不是遇到不支持的操做再报错。

诚然，RESTful只是一种风格，并无改变程序功能。是否使用RESTful，最终实现的逻辑可能彻底一致；但从系统设计角度看，形式化的东西也很重要。

###————————————————————

退一步讲，姑且不说上面的问题，RESTful自己也是先天不足的————由于HTTP在web应用方面是先天不足的，而且HTTP的设计比较简单，其报头主要用于描述HTTP通讯参数和状态，而RESTful使用HTTP动词和状态码来表示业务逻辑，没法避免语义冲突和表达能力弱的问题。

冲突是由于：前端收到的状态码，多是HTTP协议直接返回的，也多是应用逻辑返回的。咱们作过一个项目，经理要求必须用HTTP状态表示业务请求结果。我极力反对，但不被采纳。结果：404被用来表示“您查询的××不存在”，而Server宕机或接口不匹配时，APP收到的结果也是这个；405/407/410直接被HttpURLConnection抛IOException。 而且标准状态码那么少，遇到复杂些的项目，也不够用啊。固然，能够自定义状态码，可是业务逻辑侵入网络协议毫不是一个好办法。仍是使用自定义Header或自定义消息格式靠谱，虽然使用头部字段也触碰了HTTP协议，但自定义头原本就是留给应用做扩展的，并不会干扰协议工做）

还看到有人提出RESTful最好实现Hypermedia API（http://my.oschina.net/u/2337119/blog/532450） ————这也不是一个好点子。一个系统应当严控业务接口的开放程度，API应提早绑定在远端。若是“你”不知道“我”这里有哪些服务可用，那么“你”就不该该来访问“我”，由于这样的“你”应该不是一个正常的访问者，不然，“你”应当知道系统服务列表，并确切地知道每一项业务对应的具体API。上文中和github的API做比较，是错误的。Github是开放平台，原本就是面向开发者、方便开发者的，API自己就是开发者须要查询的信息，需另当别论。

可能有人会说，API的调用者实际上是系统框架内的远端APP、页面或软件，RESTful使用HTTPS能够实现安全通讯，至关于这样的API是工做在系统内部，资源直接可见不成问题。对此，我也是反对的。曾经的DES很安全，后来不行了；曾经咱们觉得MD5没问题，后来也被质疑了；如今SSL也已滴过血了，尽管暂时还算安全，谁知道哪天就挂了......绝对的网络安全是不存在的；而且SSL实现的是通讯安全，不会保证远端的应用没有被绑架。一个可靠的、健壮的系统，不能把自身的安全彻底寄托在第三方身上，必需要以本身为主，该采起的策略和措施同样不能少。

---

RESTful的诞生源于：开发人员但愿Web service和app开发的基础架构和部分通用逻辑可以标准化。这个愿望并无错，但我认为人们在HTTP协议上打算盘倒是错误的。这只能是对上述指望的一次尝试，一次使用现有工具“将就着”实现理想中新工具功能的尝试。RESTful可否最终标准化，未来应该会有正式的、完善的新协议来取代RESTful以及HTTP，或许就叫作WASP吧。 [Web Application Service Protocol]