- ASP.NET Core 2 Fundamentals
- Onur Gumus Mugilan T. S. Ragupathi
- 360字
- 2025-04-04 16:18:58
Programming Styles – RPC versus REST
Basically, there are two common styles when programming HTTP: Remote Procedure Calls and REST. Let's look at each here:
- Remote Procedure Calls: In the RPC style, we usually treat HTTP as a transport medium and do not focus on HTTP itself. We are simply piggybacking on HTTP. Our service provides some set of operations that are callable directly. In other words, from our client, we call methods as if we are calling normal methods and passing parameters. Usually, RPC is applied via SOAP (Simple Object Access Protocol), which is another XML protocol that runs on top of HTTP. RPC was popular before 2008, and these days the RESTful approach is more popular, since RPC style introduces more coupling between client and server.
- REST: REST stands for Representational State Transfer. In REST, we use URLs to represent our resources, such as https://api.example.com/books/. This URL is basically an identifier for a book collection. And for example, the following could be an identifier for the book with ID 1: https://api.example.com/books/1.
Then, we use HTTP verbs to interact with these resources. HTTP verbs and HTTP methods are synonyms. The available methods in HTTP are GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, and PATCH. So, when we make an HTTP request with GET, we are basically asking the web server to return that resource representation. And that representation can change, even for each request.
The server can return XML for one request and JSON for another, depending on what a client accepts, which is specified by the Accept header.
Why do we need REST? It is all about standardization. Suppose that we access a resource by using the GET verb; we inherently know that we are not altering anything in the server. Similarly, when we send a request via PUT, we inherently know that the requests are idempotent, meaning duplicate requests won't change anything to the same resource. Once we have this standard established, our application behaves like a browser. Just like a browser does not need documentation of an API while walking through the pages, our applications will not need documentation, but only adhere to the standards.