像 Java 的 jax-rs 一样，完整的 REST API 包含用于定义资源路径的定义，使用完整的 GET、POST、PUT 请求。
但是，通常当我遇到 REST API 时，它通常是标准 HTTP GET 请求，响应是 JSON 输出。看起来现实世界的 REST 请求的核心是使用 JSON 输出，但 REST 的真正定义允许 XML、JSON 或其他输出类型。
例如，twitter API 有“JSON”输出，它们使用 GET 请求，以下是一些 URL：
https://dev.twitter.com/docs/api/1.1/get/search/tweets
并且您仍然可以使用“GET”参数来修改请求。 twitter 的“search/tweets”功能似乎只是一个简单的 HTTP 请求，具有定义良好的 URI 路径，并且恰好返回 JSON 响应。这真的是休息吗？
对您来说，REST API 是什么？
REST（表述性状态传输）是一种模糊的架构设计模式，最早由 Roy Fieldings（又名创建 HTTP 的人）在 一篇论文 中提出。
大多数时候（99% 的时间），当有人想要 REST API 时，他们的意思是他们想要一个 Web API，在其中发送包含 HTTP 动词和描述将要执行的资源位置的 URL 的请求通过 HTTP 动词。然后，网络服务器在Resource上执行请求的动词，并将响应发送回用户。响应通常（取决于所使用的 HTTP 动词）包含结果Resource的表示。资源可以表示为 HTML、JSON、XML 或许多其他不同的mime 类型。
响应中使用的表示形式并不能真正表明 API 是否是 RESTful；它是指接口的 URL 的结构如何以及如何使用 HTTP 动词定义 Web 服务器的行为。正确兼容的 REST API 应使用 GET 动词仅读取资源、使用 POST 动词修改资源、使用 PUT 添加/替换资源以及使用 DELETE 删除资源。 HTTP 规范中列出了预期动词行为的更正式定义。
REST（简而言之）是一种范例，资源应该可以通过 URI 访问，并且可以使用类似 HTTP 的动词来操作它们（也就是说，HTTP 的设计考虑了 REST 原则）。比如说，这与您的应用程序拥有一个 URI 并发布数据负载来告诉服务器您想要实现的目标形成鲜明对比。
粗略地类比一下，文件系统通常是 RESTful 的。不同的资源位于不同的地址（目录），尽管不一定以反映路径的方式存储在磁盘上，但很容易访问和写入。另外，大多数数据库都不是 RESTful - 您连接到数据库并通过声明性 API 访问数据，而不是通过位置查找数据。
就资源是什么而言 - HTML、JSON、滑水松鼠的视频 - 这是与遵守 RESTful 原则不同的抽象级别。