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.
• 또한 두 시스템에서 생성 / 업데이트 작업을 수행 할 때 추가 데이터가 메시지 본문을 통해 전달되는 방법도 표시되지 않습니다 (예 : POST /signup또는 수행 할 때 POST /persons새 사람을 설명하는 데이터를 포함).
• 물론,이 중 어느 것도 확정 된 것은 아니지만, 직면 할 가능성이있는 항목과 일관성을 위해 자체 API를 구성하는 방법에 대한 아이디어를 제공합니다. REST URL 디자인에 대한 자세한 내용은 이 질문을 참조하십시오 .

그것은이다 HTTP를 사용하여 RPC . REST의 올바른 구현은 RPC와 달라야합니다. 방법 / 함수처럼 데이터를 처리하는 논리를 갖는 것은 RPC입니다. getAllData ()는 지능형 메서드입니다. REST는 인텔리전스를 가질 수 없으며 외부 인텔리전스에서 쿼리 할 수있는 덤프 데이터 여야합니다 .

요즘 내가 본 대부분의 구현은 RPC이지만 많은 사람들이 이것을 REST라고 잘못 부릅니다. HTTP를 사용하는 REST는 구세주이며 XML을 사용하는 SOAP는 악당입니다. 그래서 당신의 혼란은 정당화되고 당신이 옳습니다. REST가 아닙니다.

HTTP 프로토콜은 REST를 구현하지 않습니다. REST (GET, POST, PUT, PATCH, DELETE) 및 RPC (GET + POST)는 모두 HTTP (예 : Visual Studio의 웹 API 프로젝트를 통해)를 통해 개발할 수 있습니다.

좋습니다. 그렇다면 REST는 무엇입니까? Richardson 성숙 모델은 다음과 같습니다 (요약). 레벨 3 만 RESTful입니다.

• 레벨 0 : Http POST
• 레벨 1 : 각 리소스 / 엔티티에는 URI가 있습니다 (그러나 여전히 POST 만 있음)
• 레벨 2 : POST와 GET 모두 사용 가능
• 레벨 3 (RESTful) : HATEOAS (하이퍼 미디어 링크) 또는 다른 말로 자체 탐색 링크를 사용합니다.

예 : 레벨 3 (HATEOAS) :

1. Link는이 개체를 이런 방식으로 업데이트 할 수 있으며 이러한 방식으로 추가 할 수 있음을 나타냅니다.

2. 링크는이 개체를 읽을 수만 있음을 나타내며 이것이 우리가하는 방법입니다.

   분명히 데이터를 보내는 것만으로는 REST가되지 않지만 데이터를 쿼리하는 방법도 언급해야합니다. 그러나 다시, 왜 4 단계? 4 단계에 불과하고 REST라고 할 수없는 이유는 무엇입니까? Richardson은 우리에게 단계적으로 접근하는 방법을 제공했습니다.

인간이 사용할 수있는 웹 사이트를 구축했습니다. 그러나 기계에서 사용할 수있는 웹 사이트를 구축 할 수도 있습니까? 이것이 미래가있는 곳이며 RESTful 웹 서비스는이를 수행하는 방법을 보여줍니다.

• 이 책 RESTful 웹 서비스를 하는 데 도움이
• 매우 흥미로운 읽기 RPC 대 REST

추신 : REST는 매우 인기가 있으므로 자동화 된 테스트도 있지만 실제 사례에서는 .. 음 ..

REST는 리소스와 함께 작동하는 것으로 가장 잘 설명되며 RPC는 작업에 더 가깝습니다.

REST 는 Representational State Transfer를 나타냅니다. 독립 시스템 간의 상호 작용을 구성하는 간단한 방법입니다. RESTful 애플리케이션은 일반적으로 HTTP 요청을 사용하여 데이터를 게시 (생성 및 / 또는 업데이트)하고, 데이터를 읽고 (예 : 쿼리 작성), 데이터를 삭제합니다. 따라서 REST는 4 개의 모든 CRUD (Create / Read / Update / Delete) 작업에 HTTP를 사용할 수 있습니다.

RPC 는 기본적으로 사용자 요청을 처리하기 위해 여러 모듈간에 통신하는 데 사용됩니다. 예를 들어, 가상 머신을 부팅 할 때 nova, glance 및 neutron이 함께 작동하는 방식과 같은 openstack에서.

나는 이렇게 주장 할 것이다 :

내 법인이 데이터를 보유 / 소유합니까? 그런 다음 RPC : 여기 내 데이터의 일부 사본이 있습니다. 내가 보낸 데이터 사본을 조작하고 결과 사본을 내게 반환합니다.

호출 된 엔티티가 데이터를 보유 / 소유합니까? 그런 다음 REST : (1) 데이터의 일부 사본을 보여 주거나 (2) 일부 데이터를 조작합니다.

궁극적으로 데이터를 소유 / 보유하는 조치의 "측면"에 관한 것입니다. 그리고 예, REST verbiage를 사용하여 RPC 기반 시스템과 통신 할 수 있지만 그렇게 할 때 여전히 RPC 활동을 수행하게됩니다.

예 1 : DAO를 통해 관계형 데이터베이스 저장소 (또는 다른 유형의 데이터 저장소)와 통신하는 개체가 있습니다. 내 개체와 API로 존재할 수있는 데이터 액세스 개체 간의 상호 작용에 REST 스타일을 사용하는 것이 합리적입니다. 내 엔티티는 데이터를 소유 / 보유하지 않지만 관계형 데이터베이스 (또는 비 관계형 데이터 저장소)는 소유합니다.

예 2 : 복잡한 수학을 많이해야합니다. 객체에 여러 가지 수학 방법을로드하고 싶지 않고 모든 종류의 수학을 수행 할 수있는 다른 값에 일부 값을 전달하고 결과를 얻고 싶습니다. 그런 다음 RPC 스타일이 의미가 있습니다. 수학 객체 / 엔티티가 내 객체에 모든 작업을 노출하기 때문입니다. 이러한 메서드는 모두 개별 API로 노출 될 수 있으며 GET을 사용하여 호출 할 수 있습니다. HTTP GET을 통해 호출하기 때문에 이것이 RESTful이라고 주장 할 수도 있지만 실제로는 RPC입니다. 내 엔터티는 데이터를 소유 / 보유하고 원격 엔터티는 내가 보낸 데이터의 복사본에 대해 조작을 수행하고 있습니다.

HTTP를 통해 그들은 둘 다 HttpRequest객체가되고 둘 다 HttpResponse객체를 기대합니다 . 나는 그 설명으로 계속 코딩하고 다른 것에 대해 걱정할 수 있다고 생각합니다.

여기에 좋은 답변이 많이 있습니다. RPC와 REST의 차이점을 논의하는 데 정말 좋은 작업을 수행하고 여기에 대한 답변에서 읽지 않은 내용을 캡처 하기 때문에 여전히이 Google 블로그 를 참조 할 것입니다.

나는 나에게 눈에 띄는 동일한 링크에서 단락을 인용합니다.

REST 자체는 HTTP와 전세계 웹을 뒷받침하는 디자인 원칙에 대한 설명입니다. 그러나 HTTP는 상업적으로 중요한 유일한 REST API이기 때문에 대부분 REST에 대한 논의를 피하고 HTTP에만 집중할 수 있습니다. 이 대체는 사람들이 REST가 API의 맥락에서 의미한다고 생각하는 것에 많은 혼란과 가변성이 있기 때문에 유용하지만 HTTP 자체가 무엇인지에 대해서는 훨씬 더 명확하고 동의합니다. HTTP 모델은 RPC 모델의 완벽한 역입니다. RPC 모델에서 주소 지정 가능한 단위는 프로 시저이고 문제 도메인의 엔터티는 프로 시저 뒤에 숨겨져 있습니다. HTTP 모델에서 주소 지정 가능한 단위는 엔티티 자체이며 시스템의 동작은 엔티티를 생성, 업데이트 또는 삭제하는 부작용으로 엔티티 뒤에 숨겨져 있습니다.

이것이 내가 이해하고 다른 사용 사례에서 사용하는 방법입니다.

예 : 식당 관리

REST 사용 사례 : 주문 관리

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

리소스 관리를 위해 REST는 깨끗합니다. 사전 정의 된 작업이있는 하나의 끝점. DB (Sql 또는 NoSql) 또는 클래스 인스턴스를 세계에 노출하는 방법으로 볼 수 있습니다.

구현 예 :

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

프레임 워크 예제 : python 용 Falcon.

RPC 사용 사례 : 운영 관리

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

분석적, 운영 적, 비 반응 적, 비 대표적, 행동 기반 작업의 경우 RPC가 더 잘 작동하며 기능적으로 생각하는 것이 매우 자연스러운 일입니다.

구현 예 :

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

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

프레임 워크 예제 : Python 용 Flask