1.“HTTP是一个同步的请求响应式协议。这意味着它不能天然地支持服务端发起的通知（点对点），但这又是经常需要的。这就解释了为什么REST风格的应用程序中的回调需要使用应用层的设计模式，如Webhooks。现在，我们有了WebSockets这样的双向传输协议，也许工业界应该考虑在其之上根据REST原则设计一款新的应用协议。” 这一点非常有意思，因为就在差不多一年之前，我们看到有些人甚至在探讨WebSockets和REST是否能够兼容的问题。 

2.Ganesh认为，REST社区从Web Service协议栈中至少能够学到一些东西：“这些协议都是基于核心的SOAP和WS-Addressing消息机制能力之上的端到端的协议”。过去，也有人提到过类似的建议。Ganesh接着做了一个类比，他说Web Service之于WS-Addressing、WS-ReliableMessaging、WS-SecureConversation和WS-Policy好比Internet之于TCP、IP和IPSec等。Ganesh认为，REST的应用幂等性可以更好地实现可靠性（尽管并没有提到如何更好），而且可以找到REST事务的替代方案，但是他仍然留下了一个问题： 

剩下的问题是安全。WS-SecureConversation和WS-Security是可路由的，它们不同于SSL/TLS，而后者却是REST唯一的安全机制。有了WS-Sec*，就可以对消息进行部分加密，留下一些明文用于基于内容的路由和分支切换。这是REST缺乏对应的优秀方案的地方。SSL是点对点的，不受代理检测，并且违反了REST原则。REST对此只能忍受。这一说法也非常有意思，我们也看到了有的人提出了一些想法，如Resteasy的Bill Burke，他提议，REST需要更好地实现安全的方法。

1.他认为，HTTP的动词太少，尤其对于需要做点对点交互的场景。他建议：“INCLUDE（将资源加入到某个资源集合中并返回服务端设定的URI）、PLACE（使用客户端指定的URI向资源集合中添加资源）、REPLACE（全部替换）、FORCE（PLACE或REPLACE）、AMEND（部分更新，它是一个容器动词，为一个资源子集指定一个或多个动词）、MERGE（通过提供的表述合并部分资源）、RETIRE（比DELETE更好）和SOLICIT（替换GET，它也是一个容器动词，用于告知响应端对发起方的资源做些什么，因为现在是点对点的场景了）” 

2.”HTTP合并了应用层和传输层的状态码（如，304 Not Modified[未修改]和400 Bad Request[无效请求]；407 Proxy Authentication Required[需要代理认证]和502 Bad Gateway[无效网关]）。 REST在另一个协议上的实现应该更清晰地隔离应用层协议和传输层协议。HTTP承担了双份工作，因此其结果也往往不尽完美。”