JSON-RPC가 transport agnostic이라고 불리는 이유는 명세가 데이터의 모양을 정의하고 전송 방식은 강하게 제한하지 않기 때문입니다 프로토콜의 메시지 포맷을 고정해두면, 그 포맷을 어떤 통로로 보내는지는 구현 쪽 선택으로 분리할 수 있습니다 HTTP의 기능에 강하게 기대지 않는 설계 REST는 HTTP의 기능을 비교적 직접적으로 활용합니다 HTTP method로 행위를 구분 HTTP status code로 성공과 에러를 표현 반면 JSON-RPC는 HTTP를 사용하더라도 보통 단일 엔드포인트와 단일 HTTP method 중심으로 동작하는 경우가 많습니다 성공 여부와 에러는 대체로 JSON 본문 안의 result 또는 error로 표현합니다 ...
개념을 먼저 레이어로 분리 HTTP에서 인증을 얘기할 때는 보통 아래 4축으로 보면 정리가 빠름 자격 증명을 매 요청에 직접 보내는 방식 서버가 저장한 상태를 식별자로 조회하는 방식 토큰 자체를 검증하는 방식 외부 인증 또는 권한 위임 프레임워크를 이용하는 방식 조금 더 구조적으로 나누면 다음처럼 분류 가능함 Credential-based Basic Auth Digest Auth API Key Client Certificate mTLS Stateful Identifier-based Session ID Opaque Token Stateless Token-based JWT PASETO 기타 signed token Authentication / Authorization Framework OAuth 2.0 OpenID Connect SAML HTTP 기반 웹 SSO 맥락 여기서 중요한 건 인증과 인가, 전달 메커니즘이 섞여서 헷갈리는 경우가 많다는 점임 ...
개요 운영 중인 서비스에서 전체 트래픽을 한 번에 신규 기능이나 신규 인프라로 전환하지 않고, 일정 비율만 점진적으로 이동하는 전략이 필요함 주요 활용 맥락 A/B 테스트로 실험군과 통제군 분리 카나리 배포로 신규 버전을 소수 사용자에게만 적용 신규 데이터베이스, 캐시, 인덱스 전환 검증 신규 알고리즘, 추천 엔진, 정책 점진 적용 서버 비용 최적화를 위한 점진적 트래픽 이동 아래는 대부분의 시나리오에 적용 가능한 일반화된 트래픽 분배 기법 정리 요구 조건 Deterministic — 같은 사용자나 리소스는 항상 같은 그룹에 속해야 함 요청마다 그룹이 바뀌면 실험 신뢰성이 떨어지고 디버깅이 어려움 안정적 해시 기반 결정 방식 필요 ...