웹 응용 프로그램 용 API를 개발하기 위해 REST와 JSON-RPC 중에서 선택하려고합니다. 그들은 어떻게 비교합니까?
업데이트 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는 상태 비 저장이므로 설계하기가 훨씬 쉬워지고 (복잡한 오토 마톤에서 전환을 잊어 버리기가 매우 쉽습니다) 독립 소프트웨어 부분과 통합 할 수 있습니다.
- 캐시 방식으로 쉽게 통합 할 수있는 안전한 방법으로 읽기 방법을 설계 하게됩니다.
- 타임 아웃을 훨씬 더 잘 처리 할 수있는 디자인 쓰기 방법을 dem 등식 으로 설계 하게됩니다.
둘째, 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 / 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 개발자에게 실제로 도움이 될 수있는 것입니다. 작년 동안 내가 해왔 던 프레임 워크는 지금 궁금해하는 것과 같은 질문에서 시작되었습니다. :
기능 테스트를위한 내장 저장소 브라우저 (JSON 스키마 덕분에) 및 일련의 예제 서비스를 보여주는 라이브 데모를 여기에서 볼 수 있습니다.
그것이 배우자를 돕기를 바랍니다!
나쵸
답변
서비스가 모델 및 GET / POST / PUT / DELETE 패턴에서만 제대로 작동하는 경우 순수 REST를 사용하십시오.
HTTP는 원래 상태 비 저장 응용 프로그램 용으로 설계되었다는 데 동의합니다.
그러나 웹 소켓을 사용하고자하는 현대적이고 더 복잡한 (!) 실시간 (웹) 애플리케이션의 경우 (주로 상태 저장을 의미 함) 두 가지를 모두 사용하지 않는 이유는 무엇입니까? 웹 소켓을 통한 JSON-RPC는 매우 가볍기 때문에 다음과 같은 이점이 있습니다.
- 모든 클라이언트에서 즉시 업데이트 (모델 업데이트를 위해 자체 서버 간 RPC 호출 정의)
- 복잡성을 추가하기 쉬움 (REST 만 사용하여 Etherpad 복제본 만들기)
- 제대로 수행하면 (실시간에 추가로 RPC 만 추가) 대부분은 REST로만 계속 사용할 수 있습니다 (주요 기능이 채팅 등인 경우 제외)
서버 측 API 만 설계 할 때 REST 모델 정의부터 시작하여 나중에 RPC 호출 수를 최소로 유지하면서 필요에 따라 JSON-RPC 지원을 추가하십시오.
(괄호 남용으로 죄송합니다)
답변
나는 과거에 REST를 좋아했으며 RPC on paper보다 많은 이점을 가지고 있습니다. 클라이언트에게 다양한 컨텐츠 유형, 캐싱, HTTP 상태 코드 재사용을 제공 할 수 있으며 API를 통해 클라이언트를 안내 할 수 있으며 API 자체에 설명이없는 경우 API에 문서를 포함시킬 수 있습니다.
그러나 내 경험에 따르면 실제로 이것은 유지되지 않으며 대신 모든 것을 올바르게하기 위해 많은 불필요한 작업을 수행합니다. 또한 HTTP 상태 코드는 종종 도메인 논리에 정확하게 매핑되지 않으며 컨텍스트에서 코드를 사용하는 경우가 종종 있습니다. 그러나 제 생각에 REST에 대한 최악의 점은 리소스와 리소스가 허용하는 상호 작용을 디자인하는 데 많은 시간을 소비한다는 것입니다. 그리고 API에 몇 가지 중요한 추가 기능을 추가 할 때마다 새로운 기능을 추가 할 수있는 좋은 솔루션을 찾고 있으며 이미 구석에 자신을 디자인하지 않았기를 바랍니다.
대부분의 경우 이미 원격 프로 시저 호출 집합으로 API를 모델링하는 방법에 대해 완벽하고 훌륭하고 명백한 아이디어를 가지고 있기 때문에 이것은 종종 시간 낭비처럼 느껴집니다. REST의 제약 조건 내에서 문제를 모델링하기 위해이 모든 노력을 기울인다면 다음 문제는 클라이언트에서 호출하는 방법입니다. 우리의 프로그램은 호출 프로 시저를 기반으로하므로 좋은 RPC 클라이언트 라이브러리를 작성하는 것은 쉽지 않습니다. 좋은 REST 클라이언트 라이브러리를 그렇게 많이 구축하지 않으며 대부분의 경우 서버의 REST API에서 클라이언트의 프로 시저 세트로 다시 맵핑합니다. 도서관.
이 때문에 RPC는 오늘날 훨씬 단순하고 자연스럽게 느껴집니다. 내가 정말로 그리워하는 것은 자체 설명하고 상호 운용 가능한 RPC 서비스를 쉽게 작성할 수있는 일관된 프레임 워크입니다. 따라서 나 자신을 위해 RPC를 더 쉽게 만들 수있는 새로운 방법을 실험하기 위해 내 자신의 프로젝트를 만들었고 다른 누군가도 유용하다고 생각할 수도 있습니다. https://github.com/aheck/reflectrpc
