웹 애플리케이션에서 RPC와 유사한 메커니즘 대신 REST가 일반적으로 사용되는 이유는 무엇입니까?

나는 최근에 내가 아는 일반적인 웹 응용 프로그램 프레임 워크와 비교할 때 웹 응용 프로그램에 다소 특이한 사용자 지정 프레임 워크를 사용하는 회사에서 시작했습니다. RESTful 웹 서비스 대신 서버와 통신하는 데 RPC 메커니즘이 사용됩니다.

서버와 통신하는 것은 간단한 함수 호출처럼 보이지만 클라이언트가 아닌 서버에서 함수가 실행됩니다. 서버 측에는 클라이언트가 호출 할 수있는 기능을 정의하는 방법이 있습니다. 이것이 HTTP 요청으로 변환되는 방법에 대한 세부 사항은 완전히 요약되어 있습니다.

나는 이것을 짧은 시간 동안 만 사용했지만 꽤 편리해 보입니다. 그러나이 접근법의 단점이 무엇인지 궁금합니다. 다른 모든 사람들은 다르게 행동하는 것 같습니다. 보통 전보다 훨씬 높은 확률로 내가 어리 석거나 화려한 일을하고 있다는 신호입니다.

REST는 웹용으로 설계되었으며 웹은 REST 용으로 설계되었습니다. 두 사람이 함께 어울립니다. Roy Fielding의 2000 PhD 논문 건축 스타일과 네트워크 기반 소프트웨어 아키텍처의 디자인은 REST 라는 용어를 정의하고 도입 했으며 웹과 REST 사이에 중요한 상호 작용이 있습니다. Roy Fielding은 HTTP / 1.1에서 일했으며, 주요 저자는 그는 논문에서 REST를 설명하기 위해 거기서 배운 것을 사용했습니다.

따라서 웹과 REST가 잘 어울리는 간단한 이유는 웹의 작동 방식에서 REST의 정의를 추출했으며 웹은 REST의 구현이기 때문입니다.

그렇기 때문에 REST는 웹 서비스 및 웹 앱에 적합합니다. 이미 "인간"웹에서 작동하는 것으로 입증 된 것과 동일한 작업을 수행하고 "머신"웹에 적용하기 때문입니다.

큰 RPC합니다 (에 따라와 문제는 정확한 구현)을 기본적 거짓말을 분산 컴퓨팅의 착오 에 자세히 설명되어 있습니다, 백서 아르 논 로템 - 갈 - 오즈하여 :

1. 네트워크는 신뢰할 수 있습니다
2. 지연 시간은 0입니다
3. 대역폭은 무한하다
4. 네트워크는 안전하다
5. 토폴로지는 변하지 않습니다
6. 한 명의 관리자가 있습니다
7. 운송 비용은 0입니다
8. 네트워크는 동종입니다

이들은 새로 온 사람들이 일반적으로 분산 시스템을 만들 때 만드는 가정입니다. 물론, 그들 모두는 거짓입니다. 그리고 분산 시스템을 작성할 때 이들 모두를 고려해야합니다.

많은 RPC 구현의 문제점은 원격 호출을 로컬 호출처럼 보이게한다는 것입니다. 그러나 그들은 똑같지 않습니다.

• 시내 전화는 결코 실패하지 않습니다. 호출 한 서브 루틴 은 실패 할 수 있지만 호출 자체는 절대 실패 하지 않습니다 – 네트워크에서 원격 호출이 끊어 질 수 있습니다
• 시내 전화는 즉각적입니다. 호출 한 서브 루틴 은 오랜 시간 동안 (또는 무한 루프에 걸리면 영원히) 실행될 수 있지만 호출 자체 에는 시간이 전혀 걸리지 않습니다 (호출이 많으면 적은 수의 CPU 명령). 인라인이지만 매우 빠릅니다) – 원격 통화가 오랫동안 네트워크에 걸려있을 수 있습니다
• 서브 루틴이 정상적으로 반환되면 결과는 항상 다시 나타납니다. 원격 호출로 인해 네트워크에서 결과가 손실 될 수 있습니다
• 즉각적인 결과 – 원격 결과는 오랫동안 네트워크를 통해 이동할 수 있습니다
• 서브 루틴을 한 번 호출하면 정확히 한 번만 실행됩니다. 네트워크에서 원격 호출이 끊어 지거나 복제되어 원격 루틴이 0에서 여러 번 실행될 수 있습니다.
• 정확히 하나의 결과를 반환합니다. 원격 결과가 손실되거나 복제 될 수 있으므로 결과를 0 번 이상 얻을 수 있습니다.
• 서브 루틴을 두 번 호출하면 두 개의 결과가 표시되고 두 번째 호출 결과 이전에 첫 번째 호출 결과가 표시됩니다. RPC를 사용하면 결과를 얻지 못하거나 첫 번째 만 반환 할 수 있습니다. 또는 두 번째 또는 첫 번째 이전의 두 번째 또는 첫 번째 또는 두 번째 만 손실되고 두 번째를 두 번 얻거나 다른 방법으로 얻을 수 있습니다.
• 내가 호출하는 경우 a다음 b, 나는 결과를 다시 얻을 a다음의 결과 b -이 RPC와 함께, 바로 이전 시점의보다 일반적인 버전입니다, 당신은 어떤 순서로 두 답변 0 번 이상 중 하나를 얻을 수 있습니다

당신은 것입니다 원격 호출에 대해 위의 모든 처리해야합니다. 당신의 프레임 워크를 만드는하지만 원격 호출은 다음, 시외 전화에서 구별 할 수없는 당신이 알고하지 않기 때문에, 어떤 것들 원격 호출이 있습니다. 프레임 워크는 모든 것을 시도하고 처리 할 수 ​​있지만 문제는 다음과 같습니다. 프레임 워크는 시스템만큼 시스템에 대해 많이 알지 못합니다. 한 번에 한 번 끊어지면 실제로 중요하지 않은 통화가 있는지 여부는 알 수 없습니다. 따라서 프레임 워크는 매우 방어 적이어야하며 지연 시간과 대역폭 측면에서 비쌉니다.

특히 프레임 워크는 실제로 당신을 보호 할 수 없기 때문에 . CAP 정리는 분산 시스템이 일관 가능한 및 파티션 - 관대 한 동시에 할 수 없다는; 더 정확하게 말하면, 일단 파티션이 발생하면 시스템은 일관성과 가용 상태를 모두 유지할 수 없으며, 하나를 선택해야합니다 (일반적인 신념과 달리, 시스템이 실행 중일 때 세 가지를 모두 가질 수 없다고하는 이론은 아닙니다) 일반적으로 세 가지를 모두 가질 수 있지만 일단 파티션이 있으면 다른 두 가지 중 하나를 선택해야합니다. PACELC 정리는 시스템이 작동하는 경우에도, 당신은 절충하는 대기 시간 일관성 대 가지고 있음을 보여줌으로써 CAP 정리를 확장합니다.

이는 프레임 워크가 도메인별로 다르고 핵심 설계에 중요하기 때문에 프레임 워크가 사용자를 보호 할 수없는 중요한 절충점입니다.

얼랑의 같은 접근 방식, 명암이 수행 얼랑에서 : 작업을 모든 메시지가 원격으로 처리됩니다 보냅니다, 그들은 지역의 경우에도. 즉, 항상 위의 모든 문제를 처리 할 준비가되어 있습니다. 지역 프로세스의 경우, 이러한 않습니다 하지만, 오버 헤드 약간의 포즈. 이를 지원하기 위해 오류 처리 및 감독을 처리하기위한 많은 도구, 프레임 워크, 라이브러리, 패턴 및 숙어가 있습니다.

RPC 프레임 워크의 작동 방식과 사용중인 언어 나 라이브러리에 대해서는 설명하지 않았지만 이전의 "네트워크가 존재하지 않는 척"유형에 속하는 것으로 의심됩니다. 그것들은 작동하지 않습니다. 이다 좋아 처리하여 로컬 및 원격 호출 사이의 구별을 제거하기 위해 모든 A와 원격 호출. 추상적 인 방식으로 다른 방식으로 수행하면 네트워크 가 시스템의 일부입니다 . 네트워크 를 추상화하면 실제로 알아야 할 것을 추상화 합니다.

자, 당신은 여부를 구체적으로 완전히 다른 질문 REST 여부를 사용합니다. 위에서 설명한 것처럼 웹은 REST 용으로 설계되었으며 REST는 웹용으로 설계되었으므로 두 가지 가 함께 이해되지만 원하는 경우 다른 아키텍처 스타일을 사용할 수 있습니다. 그러나 귀하의 질문 중 적어도 일부는 "RPC가 아닌 이유"에 관한 것이며 위의 이유를 설명했습니다. 더 정확하게 사용하고 있다고 생각되는 RPC 유형 이 왜 문제가 될 수 있는지 설명 했습니다.

주석에는 이미 몇 가지 좋은 아이디어가 있습니다.

1. RPC는 일반적으로 기술별로 다릅니다.
2. 개발자가 주로 관심을 갖는 것은 REST가 아닌 JSON입니다.

JSON에는 매우 좋은 특성이 있습니다. 사람이 읽기 쉽고, 컴퓨터가 파싱하기 쉽고, Javascript는이를 즉시 기본적으로 인식합니다 (알다시피, Javascript 객체 표기법).

REST와 같은 제약 조건을 기꺼이 포기하려는 경우 원격 프로 시저 호출을 포함하여 JSON으로 원하는 모든 작업을 수행 할 수 있습니다. 적절한 프로토콜을 설정하기 만하면됩니다. 실제로 이러한 프로토콜은 이미 존재합니다 : JSON-RPC.

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

RPC와 REST는 장단점이 서로 다른 접근법 일 뿐이며 상황에 따라 가치가 있습니다. REST는 자원에 대해 작업하는 것이 가장 좋습니다. RPC는 조치에 관한 것입니다. RPC 클라이언트는 여러 가지 방법으로 서비스 구현과 밀접하게 결합되어 클라이언트를 중단시키지 않고 서비스 구현을 변경하기가 매우 어려워집니다.