blocks|key|5084027|text|为什么你认为只使用POST和GET就意味着它不是REST？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5084028|REST的要点是每个“资源”都有一个资源标识符，即URI。每个URI可能有GET、POST、PUT、DELETE。|5084029|5084030|GET+is+read|unordered-list-item|5084031|POST+is+update|5084032|PUT+is+create|5084033|DELETE+is+delete|5084034|5084035|如果您没有做其中的一些事情--比如PUT是很少见的，并且是一个潜在的安全漏洞--那么您就不会这样做。|5084036|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|X|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|Y|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

Why do you think only using POST and GET means it's not REST?

The point to REST is that each "resource" has a resource identifier, a URI. Each URI potentially has GET, POST, PUT, DELETE.

<ul>
<li>GET is read</li>
<li>POST is update</li>
<li>PUT is create</li>
<li>DELETE is delete</li>
</ul>

If you're not doing some of those things -- like PUT is kind of rare and a potential security hole -- then you don't.

blocks|key|3484330|text|如果您的GET请求不是idempotent，那么服务器和客户端之间的HTTP缓存将破坏您的应用程序。根据定义，POST请求不是幂等的，因此HTTP缓存不会缓存这些请求和结果:您仍然可以获得缓存GET请求的好处，而不会破坏应用程序的协议。大获成功。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3484331|而且，如果您需要删除对象，与执行删除操作的POST请求相比，在网络和日志上读取DELETE要容易得多。但是web浏览器很难使用DELETE动词发出超文本传输协议请求，所以更多的是针对你自己编写的客户端。|3484332|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Idempotent^0|4|3|1J|4|2O|3|B|A|0|0|L|4|13|6|1R|6|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@$9|W|A|X|1|Y]]|E|$]]|$1|F|3|G|5|6|7|Z|8|@$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

If your <code>GET</code> requests are not <a href="http://en.wikipedia.org/wiki/Idempotent" rel="nofollow">idempotent</a> then HTTP caching between your server and clients would break your application. <code>POST</code> requests are by definition not idempotent, so HTTP caches will not cache these requests and results: you still get the benefits of caching <code>GET</code> requests, without breaking your application's protocol. Great success.

And, if you ever need to delete objects, <code>DELETE</code> will be much easier to read on the wire and logs than a <code>POST</code> request that does the deletion. But web browsers cannot easily make HTTP requests with the <code>DELETE</code> verb, so it's really more for clients you've programmed yourself.

blocks|key|3484358|text|您应该使用REST，因为它确实包含了您想要对资源/对象执行的所有潜在操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3484359|删除资源GET-基于给定的conditions|3484360|POST检索资源-创建资源|unordered-list-item|3484361|
|3484362|PUT-使用给定的更新后的资源更新资源-|3484363|3484364|另一个原因是它是一个每个人都可以实现和使用的标准。要了解为什么标准化很重要，我建议阅读this和this+(它很有趣，但确实可以帮助人们理解REST的概念)。|offset|length|3484365|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/243388/what-exactly-does-rest-mean-what-is-it-and-why-is-it-getting-big-now/243714#243714|1|http://tomayko.com/writings/rest-to-my-wife^0|0|0|0|0|0|0|17|4|0|1C|4|1|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|11|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|13|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@$N|16|O|17|1|18]|$N|19|O|1A|1|1B]]|A|$]]|$1|P|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W]]|X|$5|S|T|U|A|$V|Y]]]]

You should use REST because it really encompasses all the potential actions you want to do on a resource/object.

<ul>
<li>GET - Retrieve a resource based on given conditions</li>
<li>POST - create a resource</li>
<li>PUT - update a resource with the given updated attributes</li>
<li>DELETE - delete a resource</li>
</ul>

Another reason is that it is a standard that everyone can implement and use. To read up on why standardization is important, I would suggest reading <a href="https://stackoverflow.com/questions/243388/what-exactly-does-rest-mean-what-is-it-and-why-is-it-getting-big-now/243714#243714">this</a> and <a href="http://tomayko.com/writings/rest-to-my-wife" rel="nofollow noreferrer">this</a> (it is rather funny, but really helps people grasp the concept of REST).

blocks|key|1417546|text|正确使用REST可以帮助您的系统组件保持适当的解耦，并且比起以典型的类似RPC的方式将它们直接绑定在一起，将来可以更容易地进行演化。这是一个架构选择，您必须根据应用程序的需求做出选择。其他人注意到了一些技术上的好处，它们也应该被考虑在内。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1417547|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Using REST correctly can help your system components remain properly decoupled and can be evolved more easily in the future than if you had tied them directly together in a typical RPC-like fashion. It's an architectural choice that you must make based on your application's needs. Others have noted some of the technical benefits, and they should be taken into account too.

blocks|key|1417581|text|罗伊·菲尔丁在博客中表达了对RPCs+masquerading+as+REST的一些不满。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1417582|REST需要使用超文本，因为客户端和服务器是非常松散耦合的，所以超文本的伸缩性非常好。使用REST，服务器可以随意更改公开的资源。在REST本身定义的基础上，没有固定的API。客户端只需要知道初始URI，然后从服务器提供的选项中选择导航或执行操作。服务器可以将代码下载到客户端，这有助于导航和状态表示。|1417583|所有这一切都与各种远程过程调用(RPC)方案形成了鲜明对比，在RPC方案中，客户机和服务器必须就一个详细的协议达成一致，该协议通常需要编译到两端(例如，一个极端以特定顺序访问的特定形式的URI，另一个极端是SOAP/WSDL/WS*+)。这种方法很脆弱，因为任何更改都需要同时在服务器端和客户端实现。随着服务器和/或客户端数量的增加，它很快就变得站不住脚。服务器尤其受到影响，因为随着受欢迎程度的增加，发布的API的演变变得越来越困难。|1417584|考虑到这些因素，在可能的情况下，REST总是更好的选择。它允许服务器的快速发展，并允许天文数字的应用程序在特别的基础上自由交互(例如，整个互联网)。|1417585|但是“当可能的时候”这一部分又如何呢？当循环中有人类时，REST工作得最好。毕竟，当面对一组以前未知的选项时，人类很有可能做出理性的选择。机器还没有出现。Web+RPC协议的诞生恰好是为了将双方都束缚在一个固定的协议上。这使得当人类被从图片中移除时，自动化过程更容易进行通信。当纯粹的自动化操作比演进和可伸缩性更重要时，RPC是一个有效的设计选择(在Internet时间和Internet规模上)。|1417586|规模和耦合？|style|BOLD|1417587|这里的“规模”指的是广义的。它包括用户和会话的数量，是的，但也包括应用程序大小和开发过程。紧密耦合严重阻碍了应用程序的规模。如果没有REST架构提供的极端松散耦合，很难想象已知最大的应用程序--万维网的存在。全球数以百万计的开发人员合作构建了这个支持数十亿用户的应用程序。然而，开发人员在做这件事时却幸灾乐祸地彼此不知道(或者至少如果不是因为StackOverflow，他们就不会知道对方)。|1417588|REST的主要支持原则是超文本。体系结构的其他元素存在，以非常大的规模(在任何意义上)支持这一原则。REST是构建Web的唯一可能的方式吗？不是的。但它恰好是非常成功的事实上的标准。它应该是任何进入生态系统的新成员的默认选择，只有在仔细和明确的设计考虑之后才会放弃。|1417589|entityMap|0|LINK|mutability|MUTABLE|url|http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven^0|E|P|0|0|0|0|0|0|0|6|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|16|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|17|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|18|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|19|8|@$A|1A|B|1B|N|O]]|9|@]|C|$]]|$1|P|3|Q|5|6|7|1C|8|@]|9|@]|C|$]]|$1|R|3|S|5|6|7|1D|8|@]|9|@]|C|$]]|$1|T|3|-4|5|6|7|1E|8|@]|9|@]|C|$]]]|U|$V|$5|W|X|Y|C|$Z|10]]]]

Roy Fielding blogged with some frustration about <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" rel="noreferrer">RPCs masquerading as REST</a>.

REST demands the use of hypertext, which scales very well since the client and server are very loosely coupled. With REST, the server is free to change the exposed resources at will. There is no fixed API above and beyond what REST itself defines. The client needs only know the initial URI, and subsequently chooses from server-supplied choices to navigate or perform actions. A server may download code to the client which aids in navigation and state representation.

All of this is in stark contrast with the various remote procedure call (RPC) schemes in which the client and server must agree upon a detailed protocol that typically needs to be compiled into both ends (e.g. URIs of a particular form accessed in a particular order at one extreme, SOAP/WSDL/WS* at the other). This approach is brittle, because any changes need to implemented on both the server and client sides at the same time. It rapidly becomes untenable as the number of servers and/or clients grows. Servers in particular suffer because evolution of the published API becomes progressively more difficult as popularity increases.

In light of these factors, REST is always the better choice when possible. It allows for rapid evolution of servers and allows an astronomical number of applications to interact freely on an ad hoc basis (e.g. the whole Internet).

But what about the "when possible" part? REST works best when there is a human in the loop. After all, a human has a good chance of being able to make a rational choice when presented with a previously unknown set of options. Machines aren't there yet. Web RPC protocols were born precisely to handcuff both sides to a fixed protocol. This makes it easier for automated processes to communicate when the human is removed from the picture. An RPC is a valid design choice when purely automated operation is more important than evolution and scalability (in Internet time and on an Internet scale).

Scale and Coupling?

"Scale" here is meant in a broad sense. It includes numbers of users and sessions, yes, but also application size and development process. Tight coupling presents a severe impediment to application size. It is hard to imagine the existence of the largest known application, the World-Wide Web, without the extremely loose coupling afforded by the REST architecture. Millions of developers around the globe have collaborated to build this application that supports billions of users. Yet the developers do this while remaining blissfully unaware of each other (or at least they would be unaware of each other if it weren't for StackOverflow ;).

The primary enabling principle of REST is hypertext. The other elements of the architecture exist to support that principle in very large scale (in every sense). Is REST the only conceivable way that the Web could have been built? No. But it happens to be the wildly successful de facto standard. It should be the default choice for any new entry into the ecosystem, discarded only after careful and explicit design consideration.

blocks|key|2059147|text|在REST中发现要容易得多。我们有WADL文档(类似于传统We服务中的WSDL+)，可以帮助您向世界宣传您的服务。您也可以使用UDDI发现。使用传统的HTTP+POST和GET，人们可能不知道您的消息、请求和响应模式来呼叫您。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2059148|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Discovery is far easier in REST. We have WADL documents (similar to WSDL in traditional webservices) that will help you to advertise your service to the world. You can use UDDI discoveries as well. With traditional HTTP POST and GET people may not know your message request and response schemas to call you.

blocks|key|3484548|text|REST允许API设计的简单演变。这就是REST的关键所在--您正在创建一个API。有些评论触及了这一思想的各个方面，但实际上并没有将核心问题带入生活。当您处理REST时，您正在创建一个供客户端(或您自己)使用的API。资源上的HTTP操作为客户端提供了API设计和功能的明确指示。因此，当我们正确地使用正确的HTTP动词时，我们就声明了一个从客户端角度来看是标准化和可理解的API。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3484549|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

REST allows easy evolution of an API design. And that's the key with REST - you're creating an API. Some of the comments have touched on aspects of this thought, but have not actually brought the core issue to life. When you are dealing with REST, you are creating an API that would be used by clients (or yourself). The HTTP actions on the resources give a clear indication to the clients of the API design and functionality. Therefore, when we use the correct HTTP verbs properly, we are declaring an API that is standardised and understandable from a client perspective.

blocks|key|5084257|text|您应该使用REST，因为它具有以下特性和优点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5084258|5084259|特性|blockquote|5084260|5084261|5084262|HTTP无状态客户机/服务器协议:每个都包含运行它所需的所有信息，这意味着客户机和服务器都不需要记住任何以前的状态来满足它。尽管如此，一些HTTP应用程序还是集成了高速缓存。这就配置了所谓的无状态客户端-缓存-服务器协议:可以将对特定HTTP请求的一些响应定义为可缓存，这样客户端将来就可以对相同的请求运行相同的响应。然而，该选项的存在并不意味着它是REST系统中最重要的四个数据事务:+recommended.|5084263|There规范中的POST+(创建)、GET+(读取和咨询)、PUT+(编辑)和REST中的DELETE.|ordered-list-item|5084264|Objects总是从URI操作的。该REST系统中每个资源的惟一标识符是URI，而不是其他元素。URI允许我们访问信息，以便更改或删除它，或者例如与第三方共享其确切位置。|5084265|统一接口:为了传输数据，REST系统对资源应用特定的操作(POST、GET、PUT和DELETE)，前提是它们使用URI标识。这使得使用information.|5084266|Layer系统更容易获得统一的接口，使流程系统化:组件之间的分层体系结构。每一层在REST系统中都有一个功能。|5084267|Use+of+hypermedia:+hypermedia是泰德·纳尔逊在1965年创造的一个术语，是超文本概念的扩展。这个概念被应用到网页开发中，它允许用户通过HTML链接浏览对象集。在REST+API的情况下，超媒体的概念解释了应用程序开发接口的容量，为客户端和用户提供了对数据运行特定操作的足够链接。|5084268|5084269|5084270|的优势|5084271|5084272|5084273|客户端和服务器之间的|5084274|分离:+REST协议将用户界面与服务器和数据存储完全分离。在进行开发时，这有一些优势。例如，它提高了接口到其他类型平台的可移植性，它增加了项目的可扩展性，并允许不同组件的开发演变为independently.|5084275|Visibility，可靠性和可扩展性。客户端和服务器之间的分离有一个明显的优势，那就是每个开发团队都可以扩展产品，而不会出现太多问题。它们可以迁移到其他服务器或在数据库中进行各种更改，前提是每个请求的数据发送正确。|5084276|+REST+API始终独立于平台或语言的类型:+REST+API始终适应所使用的语法或平台的类型，这为在开发中更改或测试新环境提供了相当大的自由度。使用REST+API，您可以拥有PHP、Java、Python或Node.js服务器。唯一不可缺少的是，对请求的响应应该始终使用用于信息交换的语言，通常是XML或JSON。|5084277|5084278|Source|offset|length|5084279|entityMap|0|LINK|mutability|MUTABLE|url|https://bbvaopen4u.com/en/actualidad/rest-api-what-it-and-what-are-its-advantages-project-development^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|6|0|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1N|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1R|8|@]|9|@]|A|$]]|$1|M|3|N|5|L|7|1S|8|@]|9|@]|A|$]]|$1|O|3|P|5|L|7|1T|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|1U|8|@]|9|@]|A|$]]|$1|S|3|T|5|L|7|1V|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|W|3|X|5|E|7|1Y|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|20|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|21|8|@]|9|@]|A|$]]|$1|12|3|13|5|L|7|22|8|@]|9|@]|A|$]]|$1|14|3|15|5|L|7|23|8|@]|9|@]|A|$]]|$1|16|3|17|5|L|7|24|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|25|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|26|8|@]|9|@$1B|27|1C|28|1|29]]|A|$]]|$1|1D|3|-4|5|6|7|2A|8|@]|9|@]|A|$]]]|1E|$1F|$5|1G|1H|1I|A|$1J|1K]]]]

You should use REST because of below features and advantages:

<blockquote>
 Features
</blockquote>

<ol>
<li>Stateless client/server protocol: Each HTTP contains all the necessary information to run it, which means that neither the client nor the server need to remember any previous state to satisfy it. Be that as it may, some HTTP applications incorporate a cache memory. This configures what is known as the stateless client-cache-server protocol: it is possible to define some of the responses to specific HTTP requests as cachable, so the client can run the same response for identical requests in the future. However, the fact that the option exists doesn't mean it is the most recommended.</li>
<li>There are four very important data transactions in any REST system and HTTP specification: POST (create), GET (read and consult), PUT (edit) and DELETE.</li>
<li>Objects in REST are always manipulated from the URI. It is the URI and no other element that is the sole identifier of each resource in this REST system. The URI allows us to access the information in order to change or delete it, or for example to share its exact location with third parties. </li>
<li>Uniform interface: to transfer data, the REST system applies specific actions (POST, GET, PUT and DELETE) on the resources, provided they are identified with a URI. This makes it easier to obtain a uniform interface that systematizes the process with the information.</li>
<li>Layer system: hierarchical architecture between the components. Each layer has a functionality within the REST system.</li>
<li>Use of hypermedia: hypermedia is a term coined by Ted Nelson in 1965 and is an extension of the concept of hypertext. This concept, taken to web page development, is what allows the user to browse the set of objects through HTML links. In the case of a REST API, the concept of hypermedia explains the capacity of an app development interface to provide the client and the user with the adequate links to run specific actions on the data.</li>
</ol>

<blockquote>
 Advantages
</blockquote>

<ol>
<li>Separation between the client and the server: the REST protocol totally separates the user interface from the server and the data storage. This has some advantages when making developments. For example, it improves the portability of the interface to other types of platforms, it increases the scalability of the projects, and allows the different components of the developments to be evolved independently.</li>
<li>Visibility, reliability and scalability. The separation between client and server has one evident advantage, and that is that each development team can scale the product without too much problem. They can migrate to other servers or make all kinds of changes in the database, provided the data from each request is sent correctly. The separation makes it easier to have the front and the back on different servers, and this makes the apps more flexible to work with.</li>
<li>The REST API is always independent of the type of platform or languages: the REST API always adapts to the type of syntax or platforms being used, which gives considerable freedom when changing or testing new environments within the development. With a REST API you can have PHP, Java, Python or Node.js servers. The only thing is that it is indispensable that the responses to the requests should always take place in the language used for the information exchange, normally XML or JSON. </li>
</ol>

<a href="https://bbvaopen4u.com/en/actualidad/rest-api-what-it-and-what-are-its-advantages-project-development" rel="nofollow noreferrer">Source</a>

Why should I use REST if I can get my job done with only post and get requests?

Why we should use REST?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

如果我只需要post和get请求就能完成工作，为什么还要使用REST呢？

问为什么我们应该使用REST？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么我们应该使用REST？EN