什么是REST？ 有点困惑
我是在假设REST是一个Web服务，但似乎我错误地认为这是 - 什么是REST？
我已经读过维基百科，但仍然无法将我的头围绕在它周围。 为什么要做很多地方将API称为REST API？
REST不是特定的Web服务，而是用于管理状态信息的设计概念（体系结构）。 关于此的开创性论文是Roy Thomas Fielding的论文（2000），“建筑风格和基于网络的软件体系结构的设计”（可从加利福尼亚大学欧文分校获得）。
首先阅读Ryan Tomayko的帖子我如何向我的妻子解释REST; 这是一个很好的起点。 然后阅读菲尔丁的实际论文。 这不是先进的，也不是很长（六章，180页）！ （我知道你在学校的孩子们喜欢它很短）。
编辑：我觉得这是毫无意义的尝试解释REST。 它有许多概念，如可扩展性，可见性（无状态）等，读者需要掌握，理解这些的最佳来源是实际的论文。 它远远超过POST / GET等。
REST是通常用于Web应用程序的软件设计模式。 通俗地说，这意味着它是在许多不同的项目中使用的一个常用的想法。 它代表了重新呈现国家转移 。 REST的基本思想是将服务器端的对象（如数据库表中的行）视为资源，而不是创建或销毁。
关于REST最基本的思考方式就是格式化Web应用程序的URL。 例如，如果您的资源被称为“帖子”，那么：
/posts将是一个用户将如何访问所有帖子，用于显示。
/posts/:id将是用户如何访问和查看单个帖子，基于其唯一ID检索。
/posts/new您将如何显示创建新帖子的表单。
向/users发送POST请求将是您如何在数据库级别创建新帖子的方式。
将一个PUT请求发送到/users/:id将是您如何更新给定帖子的属性，再次由唯一ID标识。
发送一个DELETE请求到/users/:id将是你如何删除一个给定的帖子，再次由一个唯一的ID标识。
据我了解，REST模式主要是通过Ruby on Rails框架普及的（对于web应用程序），这个框架强调RESTful路线。 虽然我可能是错的。
我可能不是最有资格讨论它的，但这是我学习它的方式（专门针对Rails开发）。
当有人引用“REST api”时，通常他们的意思是使用RESTful URL来检索数据的api。
REST是基于网络的软件体系结构的架构风格和设计。
REST概念被称为资源。 资源的表示必须是无状态的。 它通过一些媒体类型来表示。 媒体类型的一些示例包括XML ， JSON和RDF 。 资源由组件操纵。 组件通过标准的统一接口请求和操作资源。 在HTTP的情况下，这个接口由标准的HTTP操作组成，例如GET ， PUT ， POST ， DELETE 。
REST通常用于HTTP ，主要是由于HTTP的简单性以及它对RESTful原则的非常自然的映射。 然而，REST并不受限于任何特定的协议。
基本REST原则
客户端 - 服务器通信
客户端 - 服务器体系结构具有非常明显的关注点。 原则上，所有以REST风格构建的应用程序也必须是客户端服务器。
无状态
每个客户端对服务器的请求都要求其状态得到充分的表示。 服务器必须能够完全理解客户端请求，而无需使用任何服务器上下文或服务器会话状态。 因此，所有国家都必须留在客户身上。 稍后我们将更详细地讨论无状态表示。
可缓存
可以使用高速缓存约束，从而使响应数据能够被标记为可高速缓存或不可高速缓存。 标记为可缓存的任何数据可以被重用作对相同的后续请求的响应。
统一的界面
所有组件必须通过一个统一的界面进行交互。 因为所有组件交互都是通过这个接口进行的，所以与不同服务的交互非常简单 界面是一样的！ 这也意味着实施变更可以单独进行。 这种变化不会影响基本组件交互，因为统一接口总是不变。 一个缺点是你被困在界面中。 如果可以通过更改界面来为特定服务提供优化，那么REST禁止这样做是不可能的。 然而，光明的一面是，REST针对网络进行了优化，因此REST over HTTP非常受欢迎！
上述概念代表了REST的特性定义，并将REST架构与其他架构（如Web服务）区分开来。 请注意，REST服务是一项Web服务，但Web服务不一定是REST服务。
有关REST和上述原则的更多详细信息，请参阅REST Design Principals上的此博文。
链接地址: http://www.djcxy.com/p/71299.html