自己去试试吧

解决软件编程三大难题：变量起名，方法起名，Api 起名

• RESTful Web Services
• RESTful Web APIs
• RESTful Web Clients

你值得拥有

最近在看 java spring，你看他的 guides 上第一篇的标题就是Building a RESTful Web Service https://spring.io/guides

大部分关于 REST 的疑问都在 REST 那篇论文里有答案，你这个问题尤其是这样，所以 google 一下“架构风格与基于网络的软件架构设计”就可以了

别担心，虽然是论文，其实很容易看懂，而且已经翻译成中文了

就两点： 1、简洁 2、明确

naming things

#5 楼 @fsword 多少次将这篇论文拿出来看，每次看上一点就云里雾里了，是不是应该从一些更基础的东西看起呢？有什么好的建议？

#8 楼 @mumu 这个不知道怎么建议了，因为 REST 论文是我架构知识入门的读物之一，之前的学习对理解架构问题基本上没啥帮助，要不你说说哪里看的有困难？

REST 其实无非两点：

1. 傻 x 的开发者们，你们不要瞎弄了，大部分场景我在协议层已经设计好了！我给你讲讲我是怎么设计的：这里省略一百万字。
2. 你要是按照我协议设计来，和 Proxy（正向、反向）沟通的会更友好！

asp.net、java spring 这些框架是属于什么风格呢，与 rails 相比各自的优势劣势怎么体现

这些框架也可以用 REST，也可以不用，没有硬性规定。

我觉得这是两个问题。

第一个是网络应用的风格有哪些（Network-based Architectural Styles），REST 是一种，还有 Data-flow Styles，Replication Styles，Hierarchical Styles etc，这个在 Roy 的论文第三章都有提到（英文版论文请点这里)。而 REST 是在考量了 性能（Performance），扩张性（Scalability），容易修改（Modifiability）etc 这些网络应用的关键要素后提出的解决方案（性质参考第二章）。

第二个问题就是框架了，也就是 Rails。REST 首先只是指导原则，并没有提出任何实现的细节，而 Rails，或者其他的框架都是具体的实现，就是是尊重 REST 的原则。REST 风格的特点在于：

• Client-Server (目前普遍采用的结构方式，但是在 2000 年以前并不是这样，具体看论文)
• Stateless（是不是很眼熟，其实就是 HTTP 协议，Roy  参与了 HTTP 的定稿）
• Cache（使用缓存来优化用户访问体验）
• Uniform Interface（统一的接口定义，也就是 HTTP Verbs）
• Layered System ( 分层)
• Code-On-Demand（客户端代码，也就是 js）

所以 Rails  框架根据这些指导做出了具体的实现。对于开发者来说要做的，就剩下三个任务：

•  定义资源（Resource）
• 定义资源的表达方式（Representation, html, json, xml or custom format）
• 定义资源的状态转换（也就是资源和资源之间的 links）

符合了这样风格的框架之间没有本质的优劣区别，不同之处落在了语法上，本身语言的特性上，框架易用性（是否是 convention over configuration）等等。

P.S. 论文发表的时间是 2000 年，那是在有了实验结果以后才敢的发表（治学严谨啊），真正提出这个风格的时间大概是 1996 年。那个时候互联网还在襁褓中，所以阅读论文的时候可以抛开 rails 或其他框架的具体实现细节，就当是读一份互联网应用风格发展的简史。

上班前随意写了一些，希望有解答问题。

Rest 就是解决命名问题。让你自己写的时候不会浪费很多时间想名字，写出来也清晰明确，不管自己看还是别人都能很容易理解逻辑和结构。