JSON-RPC가 transport agnostic인 이유

JSON-RPC가 transport agnostic이라고 불리는 이유는 명세가 데이터의 모양을 정의하고 전송 방식은 강하게 제한하지 않기 때문입니다

프로토콜의 메시지 포맷을 고정해두면, 그 포맷을 어떤 통로로 보내는지는 구현 쪽 선택으로 분리할 수 있습니다

HTTP의 기능에 강하게 기대지 않는 설계

REST는 HTTP의 기능을 비교적 직접적으로 활용합니다

• HTTP method로 행위를 구분
• HTTP status code로 성공과 에러를 표현

반면 JSON-RPC는 HTTP를 사용하더라도 보통 단일 엔드포인트와 단일 HTTP method 중심으로 동작하는 경우가 많습니다

성공 여부와 에러는 대체로 JSON 본문 안의 result 또는 error로 표현합니다

이렇게 하면 운반 수단인 HTTP의 세부 동작에 로직이 강하게 결합되지 않아, 다른 전송 계층으로 바꾸기 쉬워집니다

순수한 JSON 덩어리로 약속을 고정

JSON-RPC의 핵심은 정해진 형식의 JSON 메시지입니다

{
  "jsonrpc": "2.0",
  "method": "subtract",
  "params": [42, 23],
  "id": 1
}

이 메시지를 전달할 수 있는 통로라면 형태만 맞추면 동작합니다

• TCP 소켓에 문자열로 전송
• WebSocket 같은 실시간 채널로 전송
• 같은 머신의 프로세스 간 통신인 IPC
• 시리얼 포트 같은 하드웨어 라인

중요한 점은 전송 채널이 바뀌어도 서버가 해석하는 입력 포맷이 동일하다는 것입니다

REST vs JSON-RPC 비교

왜 이런 독립성이 실전에서 필요한가

전송 수단은 환경에 따라 달라지는 경우가 많습니다

예를 들어 어떤 노드나 데몬과 통신할 때는 브라우저 환경에서는 HTTP로 붙이지만, 로컬 프로그램에서는 성능을 위해 IPC나 Unix Domain Socket 같은 방식을 쓰는 선택지가 있습니다

이때 요청 데이터 규격이 JSON-RPC로 동일하게 유지되면, 개발자는 통신 로직 전체를 다시 만들기보다는 통로만 바꾸는 대응을 할 수 있습니다

한 줄 요약

JSON-RPC는 내용물인 JSON 포맷을 고정하고 배달은 구현 쪽에서 책임지도록 분리하는 마인드라서 transport 계층에 독립적입니다