REST와 RPC 간의 웹 서비스 차이점

REST와 RPC 간의 웹 서비스 차이점

---

JSON 매개 변수를 받아들이고 메서드에 대한 특정 URL이있는 웹 서비스가 있습니다. 예 :

http://IP:PORT/API/getAllData?p={JSON}

이것은 Stateless가 아니기 때문에 REST가 아닙니다. 쿠키를 고려하고 자체 세션이 있습니다.

RPC입니까? RPC와 REST의 차이점은 무엇입니까?

---

게시 한 내용을 보는 것만으로는 REST 또는 RPC를 명확하게 구분할 수 없습니다.

REST의 한 가지 제약은 상태 비 저장이어야한다는 것입니다. 세션이있는 경우 상태가 있으므로 서비스를 RESTful로 호출 할 수 없습니다.

URL (예 :)에 작업이 있다는 사실은 getAllDataRPC를 나타냅니다. REST에서 표현을 교환하고 수행하는 작업은 HTTP 동사에 의해 지시됩니다. 또한 REST에서는 콘텐츠 협상 이 ?p={JSON}매개 변수로 수행되지 않습니다 .

서비스가 RPC인지 여부는 모르지만 RESTful은 아닙니다. 온라인에서 차이점에 대해 배울 수 있습니다. 시작하는 데 도움이되는 기사 는 RPC 및 REST의 신화에 대한 설명입니다 . 서비스 내부에 무엇이 있는지 더 잘 알고 있으므로 기능을 RPC와 비교하고 자신의 결론을 도출하십시오.

---

레스토랑에서 주문하는 것을 모델링하는 다음 HTTP API 예제를 고려하십시오.

• RPC API는 매개 변수를 허용 함수 호출과 같은 레스토랑 기능을 노출 "동사"의 관점에서 생각하고,를 통해 이러한 기능을 호출하는 HTTP 동사 가장 적합한 보인다 - A는 등등 쿼리에 대해 '수'와,하지만 이름 의 동사는 순전히 부수적이며 매번 다른 URL을 호출하기 때문에 실제 기능과는 아무런 관련이 없습니다 . 반환 코드는 직접 코딩되며 서비스 계약의 일부입니다.
• 반면 REST API 는 문제 도메인 내의 다양한 엔티티를 리소스로 모델링하고 HTTP 동사를 사용하여 이러한 리소스에 대한 트랜잭션을 나타냅니다. POST는 생성하고 PUT는 업데이트하며 GET은 읽을 수 있습니다. 동일한 URL 에서 호출되는 이러한 모든 동사 는 다른 기능을 제공합니다. 공통 HTTP 반환 코드는 요청 상태를 전달하는 데 사용됩니다.

주문을하다:

• RPC : http : // MyRestaurant : 8080 / Orders / PlaceOrder (POST : {Tacos 개체})
• REST : http : // MyRestaurant : 8080 / Orders / Order? OrderNumber = asdf (POST : {Tacos object})

주문 검색 :

• RPC : http : // MyRestaurant : 8080 / Orders / GetOrder? OrderNumber = asdf (GET)
• REST : http : // MyRestaurant : 8080 / Orders / Order? OrderNumber = asdf (GET)

주문 업데이트 :

• RPC : http : // MyRestaurant : 8080 / Orders / UpdateOrder (PUT : {Pineapple Tacos 개체})
• REST : http : // MyRestaurant : 8080 / Orders / Order? OrderNumber = asdf (PUT : {Pineapple Tacos object})

sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc 에서 가져온 예

---

다른 사람들이 말했듯이 주요 차이점은 REST는 명사 중심이고 RPC는 동사 중심이라는 것입니다. 다음과 같은 것을 보여주는 명확한 예제 표 를 포함하고 싶었습니다 .

--------------------------- + ---------------------- --------------- + --------------------------
  작업                  | RPC (작동)                      | REST (자원)
--------------------------- + ---------------------- --------------- + --------------------------
 가입 | POST / 가입 | POST / persons           
--------------------------- + ---------------------- --------------- + --------------------------
 사임 | POST / 사임 | / persons / 1234 삭제    
--------------------------- + ---------------------- --------------- + --------------------------
 사람 읽기 | GET / readPerson? personid = 1234 | GET / persons / 1234       
--------------------------- + ---------------------- --------------- + --------------------------
 사람의 항목 목록 읽기 | GET / readUsersItemsList? userid = 1234 | / persons / 1234 / items 가져 오기
--------------------------- + ---------------------- --------------- + --------------------------
 사람의 목록에 항목 추가 | POST / addItemToUsersItemsList | POST / persons / 1234 / items
--------------------------- + ---------------------- --------------- + --------------------------
 항목 업데이트 | POST / modifyItem | PUT / items / 456          
--------------------------- + ---------------------- --------------- + --------------------------
 항목 삭제 | POST / removeItem? itemId = 456 | / items / 456 삭제       
--------------------------- + ---------------------- --------------- + --------------------------

메모

• 표에서 볼 수 있듯이 REST는 특정 리소스
  (예 :) 를 식별하기 위해 URL 경로 매개 변수 GET /persons/1234를 사용하는 경향이있는 반면 RPC는 함수 입력
  (예 :)에 쿼리 매개 변수를 사용하는 경향이 있습니다 GET /readPerson?personid=1234.
• 표에는 REST API가 일반적으로 쿼리 매개 변수 (예 :)와 관련된 필터링을 처리하는 방법이 나와 있지 않습니다 GET /persons?height=tall.
• Also not shown is how with either system, when you do create/update operations, additional data is probably passed in via the message body (e.g. when you do POST /signup or POST /persons, you include data describing the new person).
• Of course, none of this is set in stone, but it gives you an idea of what you are likely to encounter and how you might want to organize your own API for consistency. For further discussion of REST URL design, see this question.

---

It is RPC using http. A correct implementation of REST should be different from RPC. To have a logic to process data, like a method/function, is RPC. getAllData() is an intelligent method. REST cannot have intelligence, it should be dump data that can be queried by an external intelligence.

Most implementation these days are RPC but many mistakenly call it as REST because they see they are not using XML/Soap but using HTTP + json. REST with HTTP is the saviour and SOAP with XML the villain. So your confusion is justified and you are right, it is not REST.

Http protocol does not make an implementation of REST. Both REST(GET, POST, PUT, PATCH, DELETE) and RPC(GET + POST) can be developed through HTTP(eg:through a web API project in visual studio).

RPC is old and every school kids know what RPC is and most of the REST developed ends up being RPC(HTTP+Json), understandably. But what is REST then? Richardson maturity model is given below(summarized). Only level 3 is RESTful.

• Level 0: Http POST
• Level 1: each resource/entity has a URI (but still only POST)
• Level 2: Both POST and GET can be used
• Level 3(RESTful): Uses HATEOAS (hyper media links) or in other words self exploratory links

eg level 3:

1. Link states this object can be updated this way, and added this way
2. Link states this object can only be read and this is how we do it.

You've built web sites that can be used by humans. But can you also build web sites that are usable by machines? That's where the future lies, and RESTful Web Services shows you how to do it.

• This book RESTful Web Services helps
• A very interesting read RPC vs REST

---

REST is best described to work with the resources, where as RPC is more about the actions.

REST stands for Representational State Transfer. It is a simple way to organize interactions between independent systems. RESTful applications commonly use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST can use HTTP for all four CRUD (Create/Read/Update/Delete) operations.

RPC is basically used to communicate across the different modules to serve user requests. e.g. In openstack like how nova, glance and neutron work together when booting a virtual machine.

---

I would argue thusly:

Does my entity hold/own the data? Then RPC: here is a copy of some of my data, manipulate the data copy I send to you and return to me a copy of your result.

Does the called entity hold/own the data? Then REST: either (1) show me a copy of some of your data or (2) manipulate some of your data.

Ultimately it is about which "side" of the action owns/holds the data. And yes, you can use REST verbiage to talk to an RPC-based system, but you will still be doing RPC activity when doing so.

Example 1: I have an object that is communicating to a relational database store (or any other type of data store) via a DAO. Makes sense to use REST style for that interaction between my object and the data access object which can exist as an API. My entity does not own/hold the data, the relational database (or non-relational data store) does.

Example 2: I need to do a lot of complex math. I don't want to load a bunch of math methods into my object, I just want to pass some values to something else that can do all kinds of math, and get a result. Then RPC style makes sense, because the math object/entity will expose to my object a whole bunch of operations. Note that these methods might all be exposed as individual APIs and I might call any of them with GET. I can even claim this is RESTful because I am calling via HTTP GET but really under the covers it is RPC. My entity owns/holds the data, the remote entity is just performing manipulations on the copies of the data that I sent to it.

---

This is how I understand and use them in different use cases:

Example: Restaurant Management

use-case for REST: order management

- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123

For resource management, REST is clean. One endpoint with pre-defined actions. It can be seen a way to expose a DB (Sql or NoSql) or class instances to the world.

Implementation Example:

class order:
    on_get(self, req, resp): doThis.
    on_patch(self, req, resp): doThat.

Framework Example: Falcon for python.

use-case for RPC: operation management

- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123

For analytical, operational, non-responsive, non-representative, action-based jobs, RPC works better and it is very natural to think functional.

Implementation Example:

@route('/operation/cook/<orderId>')
def cook(orderId): doThis.

@route('/operation/serve/<orderId>')
def serve(orderId): doThat.

Framework Example: Flask for python

---

Over HTTP they both end up being just HttpRequest objects and they both expect a HttpResponse object back. I think one can continue coding with that description and worry about something else.

ReferenceURL : https://stackoverflow.com/questions/26830431/web-service-differences-between-rest-and-rpc