REST 대 JSON-RPC?

REST 대 JSON-RPC?

---

웹 응용 프로그램 용 API를 개발하기 위해 REST와 JSON-RPC 중에서 선택하려고합니다. 어느 것이 API 클라이언트에 더 사용하기 쉬운가요?

업데이트 2015 : 클라이언트와 서버 모두에서 이해하는 기존의 성숙한 HTTP 프로토콜을 API에서 활용할 수 있기 때문에 REST를 웹 / HTTP에서 제공되는 API에 대해 개발하고 사용하기가 더 쉽다는 것을 알았습니다. 예를 들어 응답 코드, 헤더, 쿼리, 포스트 바디, 캐싱 및 기타 여러 기능을 추가 노력이나 설정없이 API에서 사용할 수 있습니다.

---

RPC의 근본적인 문제는 커플 링입니다. RPC 클라이언트는 여러 가지 방법으로 서비스 구현과 밀접하게 연결되어 있으며 클라이언트를 중단하지 않고 서비스 구현을 변경하기가 매우 어려워졌습니다.

• 클라이언트는 프로 시저 이름을 알아야합니다.
• 절차 매개 변수 순서, 유형 및 개수가 중요합니다. 클라이언트 구현을 중단하지 않고 서버 측에서 프로 시저 서명 (인수, 인수 순서, 인수 유형 등)을 변경하는 것은 쉽지 않습니다.
• RPC 스타일은 프로 시저 엔드 포인트 + 프로 시저 인수 외에는 아무 것도 노출하지 않습니다. 클라이언트가 다음에 수행 할 작업을 결정하는 것은 불가능합니다.

반면 REST 스타일에서는 제어 정보를 표현 (HTTP 헤더 + 표현)에 포함시켜 클라이언트를 안내하는 것이 매우 쉽습니다. 예를 들면 다음과 같습니다.

• 이러한 URI의 의미를 전달하는 링크 관계 유형으로 주석이 달린 링크를 포함 할 수 있습니다 (실제로 필수).
• 클라이언트 구현은 특정 프로 시저 이름 및 인수에 의존 할 필요가 없습니다. 대신 클라이언트는 메시지 형식에 의존합니다. 이를 통해 특정 미디어 형식 (예 : Atom, HTML, Collection + JSON, HAL 등)에 대해 이미 구현 된 라이브러리를 사용할 수 있습니다.
• 등록 된 (또는 도메인 별) 링크 관계에만 의존하는 한 클라이언트를 중단시키지 않고 URI를 쉽게 변경할 수 있습니다.
• 최종 사용자가 사람인 경우 양식에 유사한 구조를 표현에 포함하여 클라이언트에게 이러한 설명을 UI 기능으로 노출 할 수 있습니다.
• 캐싱 지원은 추가 이점입니다.
• 표준화 된 상태 코드;

REST 측에는 더 많은 차이점과 장점이 있습니다.

---

문제를 좀 더 자세히 살펴보고 순수 REST가 너무 제한적이며 RPC가 가장 좋습니다. 대부분의 앱은 CRUD 앱입니다. REST를 고수하면 결국 특별한 목적을 위해 API에 다른 필요한 메소드를 쉽게 추가하는 방법에 대해 궁금해 할 것입니다. 많은 경우에 REST를 사용하여이를 수행하는 유일한 방법은 다른 컨트롤러를 작성하는 것인데, 이로 인해 프로그램이 과도하게 복잡해질 수 있습니다.

RPC를 결정할 경우 유일한 차이점은 동사를 URI의 일부로 명시 적으로 지정한다는 것입니다. 명확하고 일관되며 버그가 적으며 실제로 문제가 없습니다. 특히 간단한 CRUD를 넘어서는 앱을 만드는 경우 RPC가 유일한 방법입니다. RESTful 순수 주의자에게 또 다른 문제가 있습니다 .HTTP POST, GET, PUT, DELETE는 HTTP에서 명확한 의미를 지니고 있습니다 .HTTP에서 REST는 다른 것들을 의미하는 것으로 바 꾸었습니다.

프로그래밍에서, 나는 두 가지를 의미하기 위해 한 가지를 사용하려고 시도하는 것이 언젠가 와서 물릴 것이라는 것을 발견했습니다. 필자는 메소드가 필요로하는대로 데이터를 자유롭게 보내고받을 수 있기 때문에 거의 모든 작업에 POST를 사용할 수있는 기능을 원합니다. 전 세계를 CRUD에 맞출 수는 없습니다.

---

첫째, HTTP-REST는 "표현 상태 전송"아키텍처입니다. 이것은 많은 흥미로운 것들을 암시합니다.

• API는 상태가 없으므로 설계하기가 훨씬 쉬워지고 (복잡한 오토 마톤에서의 전환을 잊어 버리기가 매우 쉽습니다) 독립 소프트웨어 부분과 통합 할 수 있습니다.
• 캐시 방식으로 쉽게 통합 할 수있는 안전한 방법으로 읽기 방법을 설계 하게됩니다.
• write 등식으로 쓰기 메소드를 설계 하면 시간 초과를 훨씬 더 잘 처리 할 수 있습니다.

둘째, HTTP-REST는 HTTP와 완벽하게 호환되므로 (이전 부분의 "안전한"및 "등가"참조) HTTP 라이브러리 (기존의 모든 언어에 존재) 및 HTTP 리버스 프록시를 재사용 할 수 있습니다. 코드가없는 고급 기능 (캐시, 인증, 압축, 리디렉션, 재 작성, 로깅 등)을 구현할 수 있습니다.

마지막으로 HTTP를 RPC 프로토콜로 사용하는 것은 HTTP 1.1 (및 REST 발명자) 디자이너 http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation 에 따르면 큰 오류 입니다. htm # sec_6_5_2

---

훌륭한 답변-일부 의견을 명확히하고 싶었습니다. JSON-RPC는 빠르고 사용하기 쉽지만 언급 된 자원과 매개 변수가 밀접하게 결합되어 있으며 REST는 느슨하게 결합 된 자원 (api / api)을 제공하는 GET / POST를 사용하여 동사 (api / deleteUser, api / addUser)에 의존하는 경향이 있습니다. HTTP REST API에서 여러 HTTP 메소드 (GET, POST, PUT, PATCH, DELETE)를 사용합니다. REST는 경험이 부족한 개발자가 구현하기가 약간 어렵지만 이제는 스타일이 상당히 일반화되어 장기적으로 훨씬 더 많은 유연성을 제공합니다 (API 수명 연장).

REST는 리소스가 밀접하게 결합되지 않은 상태에서 단일 컨텐츠 유형에 전념하지 않도록합니다. 즉, 클라이언트가 XML, JSON 또는 YAML로 데이터를 수신해야하는 경우 시스템에 내장 된 경우 content-type / accept 헤더를 사용하는 것을 반환하십시오.

이를 통해 새로운 컨텐츠 유형 또는 클라이언트 요구 사항을 지원할 수 있도록 API를 유연하게 유지할 수 있습니다.

그러나 REST를 JSON-RPC와 진정으로 분리시키는 것은 아키텍처 유연성을 보장하면서 신중하게 고려 된 일련의 제약 조건을 따른다는 것입니다. 이러한 제약 조건에는 클라이언트와 서버가 서로 독립적으로 진화 할 수 있도록하는 것 (클라이언트의 응용 프로그램을 망칠 필요없이 변경 가능), 호출이 상태 비 저장 (상태가 하이퍼 미디어를 통해 표시됨), 상호 작용을위한 균일 한 인터페이스 제공, API는 계층화 된 시스템에서 개발되며 클라이언트가 응답을 캐시 할 수 있습니다. 주문형 코드를 제공하기위한 선택적 제약도 있습니다.

그러나이 모든 말로-MOST API는 하이퍼 미디어 (API 탐색을 돕는 응답에 포함 된 하이퍼 텍스트 링크)를 포함하지 않기 때문에 RESTing (Fielding에 따르면)이 아닙니다. 대부분의 API는 REST와 유사하며 REST의 개념을 대부분 따르지만이 제한 조건은 무시한다는 점에서 REST와 유사합니다. 그러나 점점 더 많은 API가이를 구현하고 있으며 더 많은 주류 관행이되고 있습니다.

또한 RPC 경로와 마찬가지로 하이퍼 미디어 기반 API (예 : Stormpath)가 클라이언트를 URI로 향하게하기 때문에 유연성이 있습니다 ( 어떤 경우에는 부정적인 영향없이 URI를 수정할 수 있음). 공전. RPC를 사용하면 이러한 서로 다른 URI를 광범위하게 문서화하고 서로 관련하여 작동하는 방식을 설명해야합니다.

일반적으로 확장 가능하고 유연한 API를 오래 유지하려는 경우 REST를 사용하는 것이 좋습니다. 이런 이유로, 나는 그것이 시간의 99 %를가는 경로라고 말할 것입니다.

행운을 빌어, 마이크

---

IMO의 핵심은 행동 대 자원 지향입니다. REST는 자원 지향적이며 CRUD 조작에 적합하며 알려진 의미론을 고려하면 첫 번째 사용자에게 약간의 예측 가능성을 제공하지만 메소드 또는 프로 시저에서 구현되면 자원 중심 세계에 인공 번역을 제공해야합니다. 반면에 RPC는 CRUD 가능 리소스 세트가 아닌 서비스를 제공하는 작업 지향 API에 완벽하게 적합합니다.

의심 할 여지없이 REST가 더 널리 사용되므로 API를 타사에 노출하려는 경우 확실히 몇 가지 사항이 추가됩니다.

그렇지 않은 경우 (예 : SPA에서 AJAX 프런트 엔드를 생성하는 경우) RPC를 선택합니다. 특히 JSON-RPC, 설명 언어로 JSON 스키마와 결합되고 사용 사례에 따라 HTTP 또는 웹 소켓을 통해 전송됩니다.

JSON-RPC 는 동기식 또는 비동기식 RPC에 사용될 요청 및 응답 JSON 페이로드를 정의하는 단순하고 우아한 사양입니다.

JSON 스키마 는 JSON 데이터를 설명하기위한 JSON 기반 형식을 정의하는 초안 사양입니다. JSON 스키마를 사용하여 서비스 입력 및 출력 메시지를 설명하면 유용성을 저하시키지 않으면 서 메시지 구조에 임의의 복잡성을 가질 수 있으며 서비스 통합을 자동화 할 수 있습니다.

전송 프로토콜 (HTTP 및 웹 소켓)의 선택은 다양한 요소에 따라 달라지며, HTTP 기능 (캐싱, 유효성 재확인, 안전성, dem 등성, 콘텐츠 유형, 멀티 파트 등)이 필요한지 또는 응용 프로그램을 교체해야하는지 여부가 가장 중요합니다 높은 빈도의 메시지.

지금까지는 문제에 대한 개인적인 견해가 많았지 만 이제는이 줄을 읽는 Java 개발자에게 실제로 도움이 될 수있는 것입니다. 작년 동안 내가 해왔 던 프레임 워크는 지금 궁금해하는 것과 같은 질문에서 나왔습니다. :

http://rpc.brutusin.org

기능 테스트를위한 내장 저장소 브라우저 (JSON 스키마 덕분에) 및 일련의 예제 서비스를 보여주는 라이브 데모를 여기에서 볼 수 있습니다.

http://demo.rpc.brutusin.org

그것이 배우자를 돕기를 바랍니다!

나쵸

---

서비스가 모델 및 GET / POST / PUT / DELETE 패턴에서만 제대로 작동하는 경우 순수한 REST를 사용하십시오.

HTTP는 원래 상태 비 저장 응용 프로그램 용으로 설계되었다는 데 동의합니다.

그러나 웹 소켓을 사용하고자하는 현대적이고 더 복잡한 (!) 실시간 (웹) 애플리케이션의 경우 (주로 상태 저장을 의미 함) 두 가지를 모두 사용하는 이유는 무엇입니까? 웹 소켓을 통한 JSON-RPC는 매우 가볍기 때문에 다음과 같은 이점이 있습니다.

• 모든 클라이언트에서 즉시 업데이트 (모델 업데이트를 위해 자체 서버 간 RPC 호출 정의)
• 복잡성을 추가하기 쉬움 (REST 만 사용하여 Etherpad 복제본 만들기)
• 제대로 수행하면 (실시간에 추가로 RPC 만 추가) 대부분은 REST에서만 사용할 수 있습니다 (주요 기능이 채팅 또는 기타 인 경우 제외)

서버 측 API 만 설계 할 때 REST 모델 정의부터 시작하여 나중에 필요에 따라 JSON-RPC 지원을 추가하여 RPC 호출 수를 최소로 유지하십시오.

(괄호 남용으로 죄송합니다)

---

나는 과거에 REST를 좋아했으며 RPC on paper보다 많은 이점을 가지고 있습니다. 클라이언트에게 다양한 컨텐츠 유형, 캐싱, HTTP 상태 코드 재사용을 제시 할 수 있으며 API를 통해 클라이언트를 안내 할 수 있으며, 대부분 자체 설명이 아닌 경우 API에 문서를 포함시킬 수 있습니다.

그러나 내 경험에 따르면 실제로 이것은 유지되지 않으며 대신 모든 것을 올바르게하기 위해 많은 불필요한 작업을 수행합니다. 또한 HTTP 상태 코드는 종종 도메인 논리에 정확하게 매핑되지 않으며 컨텍스트에서 코드를 사용하는 경우가 종종 있습니다. 그러나 제 생각에 REST에 대한 최악의 점은 리소스와 리소스가 허용하는 상호 작용을 디자인하는 데 많은 시간을 소비한다는 것입니다. 그리고 API에 몇 가지 중요한 추가 기능을 추가 할 때마다 새로운 기능을 추가 할 수있는 좋은 솔루션을 찾고 있으며 이미 구석에 자신을 디자인하지 않았기를 바랍니다.

대부분의 경우 이미 원격 프로 시저 호출 집합으로 API를 모델링하는 방법에 대해 완벽하고 훌륭하고 명백한 아이디어를 가지고 있기 때문에 이것은 종종 시간 낭비처럼 느껴집니다. REST의 제약 조건 내에서 문제를 모델링하기 위해이 모든 노력을 기울인다면 다음 문제는 클라이언트에서 호출하는 방법입니다. 우리의 프로그램은 호출 절차를 기반으로하므로 좋은 RPC 클라이언트 라이브러리를 작성하는 것은 쉽지 않습니다. 좋은 REST 클라이언트 라이브러리를 그렇게 많이 구축하지 마십시오. 대부분의 경우 서버의 REST API에서 클라이언트의 절차 세트로 다시 매핑합니다. 도서관.

이 때문에 RPC는 오늘날 훨씬 더 단순하고 자연스럽게 느껴집니다. 내가 정말로 그리워하는 것은 자체 설명하고 상호 운용 가능한 RPC 서비스를 쉽게 작성할 수있는 일관된 프레임 워크입니다. 따라서 RPC를 더 쉽게 만들 수있는 새로운 방법을 실험하기 위해 내 자신의 프로젝트를 만들었고 다른 누군가도 유용하다고 생각할 수도 있습니다. https://github.com/aheck/reflectrpc

---

Richardson 성숙 모델 에 따르면 , 질문은 REST 대 RPC 가 아니라 얼마나 많은 REST ?

이 관점에서 REST 표준 준수는 4 가지 수준으로 분류 할 수 있습니다.

• 레벨 0 : 조치 및 매개 변수 측면에서 생각하십시오. 이 기사에서 설명 하듯 이 이는 본질적으로 JSON-RPC와 동일합니다 (이 기사에서는 XML-RPC에 대해 설명하지만 두 가지 모두에 대해 동일한 인수가 사용됨).
• 1 단계 : 자원 측면에서 생각하십시오. 자원과 관련된 모든 것은 동일한 URL에 속합니다
• 레벨 2 : HTTP 동사 사용
• 3 단계 : 증오

REST 표준의 작성자에 따르면 레벨 3 서비스 만 RESTful이라고 할 수 있습니다. 그러나 이것은 품질이 아닌 컴플라이언스 메트릭입니다 . 계산을 수행하는 원격 함수를 호출하려는 경우 응답에 관련 하이퍼 미디어 링크가 있거나 사용 된 HTTP 동사를 기반으로하는 동작 구분이없는 것이 의미가 없습니다. 따라서 이러한 호출은 본질적으로 RPC와 유사한 경향이 있습니다. 그러나 컴플라이언스 수준이 낮다고해서 반드시 상태 저장 또는 높은 커플 링을 의미하는 것은 아닙니다. 아마도 REST 대 RPC 를 생각하는 대신 가능한 한 많은 REST를 사용해야하지만 더 이상은 사용하지 않아야합니다. RESTful 준수 표준에 맞게 애플리케이션을 왜곡하지 마십시오.

---

왜 JSON RPC인가 :

REST API의 경우 필요한 각 기능 / 방법에 대한 컨트롤러를 정의해야합니다. 결과적으로 클라이언트가 액세스 할 수있는 10 개의 메소드가있는 경우 클라이언트의 요청을 특정 메소드에 인터페이스하기 위해 10 개의 컨트롤러를 작성해야합니다.

또 다른 요인은 각 방법 / 기능에 따라 서로 다른 컨트롤러가 있지만 클라이언트는 POST 또는 GET을 사용해야한다는 점을 기억해야합니다. 이것은 일을 더욱 복잡하게 만듭니다. 데이터를 보내려면 POST를 사용하는 경우 요청의 내용 유형을 설정해야합니다.

JSON RPC의 경우 대부분의 JSONRPC 서버는 POST HTTP 메소드에서 작동하고 컨텐츠 유형은 항상 application / json이므로 작업이 크게 단순화됩니다. 클라이언트 측에서 적절한 HTTP 메소드 및 컨텐츠 설정을 사용하는 것을 기억해야합니다.

서버가 클라이언트에 노출시키려는 다양한 방법 / 기능에 대해 별도의 컨트롤러를 만들 필요는 없습니다.

왜 REST인가?

서버가 클라이언트 측에 노출시키려는 다른 기능에 대한 별도의 URL이 있습니다. 결과적으로 이러한 URL을 포함 할 수 있습니다.

이러한 요점의 대부분은 논쟁의 여지가 있으며 사람의 필요에 전적으로 달려 있습니다.

---

항상 그렇듯이, 그것은 달려 있다고 생각합니다 ...

REST는 광범위한 대중 지원이라는 큰 장점을 가지고 있으며 이는 많은 도구와 책을 의미합니다. 다른 조직의 많은 소비자가 사용하는 API를 만들어야하는 경우 한 가지 이유만으로도 인기가 있습니다. 프로토콜은 물론 명령을 URL / 동사 / 응답에 매핑하는 방법이 너무 많기 때문에 전체 실패입니다.

따라서 백엔드와 통신 해야하는 단일 페이지 웹 앱을 작성할 때 REST가 너무 복잡하다고 생각합니다. 이 상황에서는 앱과 API가 함께 진화 할 수 있으므로 장기 호환성에 대해 걱정할 필요가 없습니다.

한 번에 단일 페이지 웹 응용 프로그램을 위해 REST로 시작했지만 웹 응용 프로그램과 서버 사이의 세분화 된 명령으로 인해 빠르게 미쳤습니다. 경로 매개 변수로 인코딩해야합니까? 몸에? 쿼리 매개 변수? 헤더? URL / Verb / Response 디자인 후 Javascript, Java의 디코더 로이 엉망을 코딩 한 다음 실제 메소드를 호출해야했습니다. 많은 도구가 있지만 도메인 코드에서 HTTP 의미를 얻지 못하는 것은 정말 까다로운 작업입니다. (응집력)

중간 규모의 복잡한 사이트에 Swagger / OpenAPI 파일을 만들어 해당 파일의 원격 프로 시저를 설명하는 단일 Java 인터페이스와 비교해보십시오. 복잡성이 증가하고 있습니다.

따라서 단일 페이지 webapp에 대해 REST에서 JSON-RPC로 전환했습니다. a 서버에서 Java 인터페이스를 인코딩하여 브라우저에 제공 한 작은 라이브러리를 개발했습니다. 브라우저에서 이것은 각 기능에 대한 약속을 반환하는 응용 프로그램 코드에 대한 프록시를 만들었습니다.

다시 말하지만 REST는 유명하기 때문에 잘 지원되고 있습니다. 기본 상태 비 저장 리소스 철학과 계층 적 모델을 인식하는 것도 중요합니다. 그러나 이러한 원칙은 RPC 모델에서도 쉽게 사용할 수 있습니다. JSON은 HTTP를 통해 작동하므로이 영역에서 REST와 동일한 장점을 갖습니다. 차이점은 필연적으로 이러한 원칙에 잘 맞지 않는 이러한 기능을 실행할 때 불필요한 작업을 많이 수행하지 않아도된다는 것입니다.

---

REST는 HTTP와 밀접하게 연결되어 있으므로 API over HTTP 만 공개하는 경우 REST는 대부분의 상황에 적합합니다. 그러나 메시징 또는 웹 소켓과 같은 다른 전송을 통해 API를 노출해야하는 경우 REST는 적용 할 수 없습니다.

---

이해하기 쉬운 웹 애플리케이션 용 API를 개발하려면 REST와 JSON-RPC 중에서 JSON-RPC를 선택하는 것이 좋습니다. 메소드 호출 및 통신에 대한 맵핑을 쉽게 이해할 수 있으므로 JSON-RPC가 선호됩니다.

가장 적합한 접근법을 선택하는 것은 제약이나 주요 목표에 달려 있습니다. 예를 들어 성능이 주요 특성 인 경우 JSON-RPC (예 : 고성능 컴퓨팅)를 사용하는 것이 좋습니다. 그러나 다른 사람들이 추론 할 수있는 일반적인 인터페이스를 제공하기 위해 주요 목표가 불가지론이라면 REST를 사용하는 것이 좋습니다. 두 가지 목표를 모두 달성해야하는 경우 두 프로토콜을 모두 포함하는 것이 좋습니다.

실제로 REST를 JSON-RPC와 분리하는 사실은 아키텍처 유연성을 확인하는 신중하게 고려 된 일련의 제약 조건을 따르는 것입니다. 제약 조건은 클라이언트와 서버가 서로 독립적으로 성장할 수 있도록 (클라이언트의 응용 프로그램을 망칠 필요없이 변경 가능), 호출은 상태 비 저장 (상태는 하이퍼 미디어로 간주 됨) 균일 인터페이스는 상호 작용을 위해 제공되며 API는 계층 시스템에서 고급화됩니다 (Hall, 2010). JSON-RPC는 빠르며 소비하기 쉽지만, 언급 된 리소스와 매개 변수가 밀접하게 연결되어 있고 GET / POST를 사용하는 동사 (api / addUser, api / deleteUser)에 의존하는 반면 REST는 느슨하게 연결된 리소스 (api / users)를 HTTP에 추가하십시오. REST API는 GET, PUT, POST, DELETE, PATCH와 같은 여러 HTTP 메소드에 의존합니다.

가벼운 데이터 교환 형식 인 JSON (JavaScript Object Notation으로 표시)은 사람이 읽고 쓸 수 있습니다. 기계가 구문 분석하고 생성하는 데 어려움이 없습니다. JSON은 전적으로 언어에 독립적 인 텍스트 형식이지만 C #, C, C ++, Java, Perl, JavaScript, Python 및 기타 여러 언어로 구성된 언어 제품군의 프로그래머에게 익숙한 규칙을 실행합니다. 이러한 속성으로 인해 JSON은 완벽한 데이터 교환 언어이며 더 나은 선택이 가능합니다.

---

잘못된 질문 : 존재하지 않는 manichean을 부과합니다!

JSON-RPC를 "less verb"( 메소드 없음 )와 함께 사용 하고 sendo id, 매개 변수, 오류 코드 및 경고 메시지에 필요한 최소한의 표준화를 유지할 수 있습니다. JSON-RPC 표준은 "휴식을 할 수 없습니다"라고 말하지 않고 기본 정보를 포장하는 방법 만 말합니다.

"REST JSON-RPC"가 존재합니다 ! 간단하고 확실한 계약을 통해 최소한의 정보 포장을 위해 "모범 사례"를 갖춘 REST입니다.

---

예

( 이 답변 과 교훈적인 맥락에서)

REST를 다룰 때 일반적으로 리소스 측면에서 생각하는 것이 좋습니다. 이 경우, 자원은 "은행 계좌"가 아니라 해당 은행 계좌의 거래입니다. 그러나 JSON-RPC는 "method"매개 변수를 의무화하지 않으며 모두 엔드 포인트의 "경로"로 인코딩됩니다.

• REST 예금 과 POST /Bank/Account/John/TransactionJSON 요청과 {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
  JSON 응답은 다음과 같습니다.{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• REST Withdraw with POST /Bank/Account/John/Transaction...와 유사합니다.

• ... GET /Bank/Account/John/Transaction/12345@13... 정확한 거래에 대한 JSON 레코드를 반환 할 수 있습니다 (예 : 사용자는 일반적으로 자신의 계정에 차변 및 크레딧 레코드를 원함). 로 뭔가 {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. (REST) ​​GET 요청에 대한 규칙에는 "@id"에 의한 id 인코딩이 포함될 수 있으므로 JSON을 보낼 필요는 없지만 응답 팩에서 여전히 JSON-RPC를 사용합니다.

---

리소스를 요청하면 설계 상 RESTful API가 더 좋습니다. 간단한 CRUD 이외의 많은 매개 변수와 복잡한 방법으로 복잡한 데이터를 요청하는 경우 RPC가 올바른 방법입니다.

---

RPC 프로토콜에 vdata를 사용합니다 : http://vdata.dekuan.org/

1, PHP와 JavaScript는 모두 괜찮습니다. 2, CORS (Cross-origin resource sharing) 통화는 여전히 괜찮습니다.

참고 URL : https://stackoverflow.com/questions/15056878/rest-vs-json-rpc