최영선의 블로그

같은 작업을 해도 어떤 API는 클라이언트가 다음 행동을 쉽게 고르고, 어떤 API는 성공인지 실패인지부터 다시 해석하게 만듭니다. 그 차이는 대개 메서드 이름이 아니라 method와 status code를 얼마나 일관되게 묶어 썼는지에서 나옵니다.여기서는 GET, POST, PATCH, DELETE를 단순 암기가 아니라 클라이언트 분기 규칙으로 정리합니다. 응답 숫자를 어떻게 고르느냐가 재시도, 캐시, 에러 처리까지 함께 결정하기 때문입니다.API Design 101 4장 흐름 개요먼저 던지는 질문GET, POST, PUT, PATCH, DELETE는 각각 무엇을 의미할까요?safe와 idempotent는 어떻게 다를까요?2xx, 3xx, 4xx, 5xx 계열은 어떻게 읽어야 할까요?왜 중요한가meth..

비슷해 보이는 두 API가 실제로는 전혀 다르게 느껴지는 이유는 대개 REST라는 이름 때문이 아니라 예측 가능성 때문입니다. URL은 그럴듯한데 호출할 때마다 규칙이 달라지면, 클라이언트는 문서를 읽고도 계속 추측해야 합니다.여기서는 REST를 URL 스타일이 아니라 여섯 가지 제약이 만드는 설계 규율로 정리합니다. 그래야 이후 글에서 리소스, 메서드, 캐시, 문서 구조를 따로 배워도 같은 방향으로 이해할 수 있습니다.REST의 계층 구조: 클라이언트 → 캐시/LB → 서버 → 데이터먼저 던지는 질문REST는 어디서 나왔고 무엇을 뜻할까요?REST를 이루는 여섯 가지 아키텍처 제약은 무엇일까요?리소스 중심 사고는 RPC 스타일과 어떻게 다를까요?REST의 탄생과 핵심 정의REST(Representati..

팀이 같은 기능을 각자 다른 방식으로 호출하기 시작하면, 그때부터 구현 문제가 아니라 계약 문제가 터집니다. 서버 코드는 멀쩡한데도 호출 규칙이 흐릿하면 클라이언트마다 다른 가정을 붙이고, 작은 변경이 바깥에서는 장애처럼 번집니다.여기서는 API를 단순한 함수 호출이나 URL 집합이 아니라, 오래 유지해야 하는 외부 계약으로 보는 관점을 먼저 세웁니다. 그래야 이후 글에서 다룰 REST, 리소스, 상태 코드, 문서화 원칙이 한 흐름으로 연결됩니다.클라이언트와 서버 사이에 API 계약이 놓이는 구조먼저 던지는 질문API는 정확히 무엇이며, 왜 시스템의 외부 계약이라고 부를까요?라이브러리 API와 웹 API는 무엇이 같고 무엇이 다를까요?좋은 API라고 부르려면 어떤 조건을 갖춰야 할까요?API란 정확히 무..

이 글은 Backend Development 101 시리즈의 두 번째 글입니다.브라우저에서 버튼을 눌렀는데 응답이 끊기거나, 프록시를 거치자 인증이 갑자기 풀리거나, 모니터링은 전부 200인데 사용자 문의는 계속 들어오는 날이 있습니다. 이때 프레임워크 API만 보고 있으면 원인이 흐려집니다. 요청과 응답이 실제로 어떤 바이트로 오가는지, 그 바이트를 누가 어떤 규칙으로 해석하는지까지 내려가야 문제가 풀립니다.Backend Development 101 2장 흐름 개요먼저 던지는 질문HTTP 요청과 응답은 실제로 어떤 모양의 텍스트일까요?HTTP는 TCP 위에서 어떻게 동작할까요?status code와 header는 왜 단순 장식이 아니라 계약일까요?HTTP는 텍스트 프로토콜입니다HTTP/1.x를 이해하는..

이 글은 Backend Development 101 시리즈의 첫 번째 글입니다.회원가입은 잘 되는데 로그인은 가끔 실패하고, 주문은 접수됐는데 재고는 마이너스로 떨어지고, 배포 직후부터 API 지연이 급증하는 상황을 팀에서 한 번쯤 겪습니다. 화면은 멀쩡한데 서비스가 흔들릴 때 원인은 대부분 백엔드의 책임 경계가 흐려진 지점에서 시작됩니다. 이 글은 "백엔드가 데이터를 처리한다" 수준을 넘어, 운영에서 버티는 구조를 어떻게 이해해야 하는지에 집중합니다. Backend Development 101 1장 흐름 개요먼저 던지는 질문백엔드는 정확히 어떤 역할과 경계를 가지는 계층일까요?하나의 요청은 HTTP 서버, 라우터, 서비스, 데이터베이스를 어떻게 통과할까요?왜 백엔드를 한 덩어리가 아니라 여러 레이어로 ..

같은 작업을 해도 어떤 API는 클라이언트가 다음 행동을 쉽게 고르고, 어떤 API는 성공인지 실패인지부터 다시 해석하게 만듭니다. 그 차이는 대개 메서드 이름이 아니라 method와 status code를 얼마나 일관되게 묶어 썼는지에서 나옵니다.이 글은 API Design 101 시리즈의 네 번째 글입니다.여기서는 GET, POST, PATCH, DELETE를 단순 암기가 아니라 클라이언트 분기 규칙으로 정리합니다. 응답 숫자를 어떻게 고르느냐가 재시도, 캐시, 에러 처리까지 함께 결정하기 때문입니다.먼저 던지는 질문GET, POST, PUT, PATCH, DELETE는 각각 무엇을 의미할까요?safe와 idempotent는 어떻게 다를까요?2xx, 3xx, 4xx, 5xx 계열은 어떻게 읽어야 할까..

비슷해 보이는 두 API가 실제로는 전혀 다르게 느껴지는 이유는 대개 REST라는 이름 때문이 아니라 예측 가능성 때문입니다. URL은 그럴듯한데 호출할 때마다 규칙이 달라지면, 클라이언트는 문서를 읽고도 계속 추측해야 합니다.이 글은 API Design 101 시리즈의 두 번째 글입니다.여기서는 REST를 URL 스타일이 아니라 여섯 가지 제약이 만드는 설계 규율로 정리합니다. 그래야 이후 글에서 리소스, 메서드, 캐시, 문서 구조를 따로 배워도 같은 방향으로 이해할 수 있습니다.먼저 던지는 질문REST는 어디서 나왔고 무엇을 뜻할까요?REST를 이루는 여섯 가지 아키텍처 제약은 무엇일까요?리소스 중심 사고는 RPC 스타일과 어떻게 다를까요?큰 그림API Design 101 2장 흐름 개요이 그림에서는..

팀이 같은 기능을 각자 다른 방식으로 호출하기 시작하면, 그때부터 구현 문제가 아니라 계약 문제가 터집니다. 서버 코드는 멀쩡한데도 호출 규칙이 흐릿하면 클라이언트마다 다른 가정을 붙이고, 작은 변경이 바깥에서는 장애처럼 번집니다.이 글은 API Design 101 시리즈의 첫 번째 글입니다.여기서는 API를 단순한 함수 호출이나 URL 집합이 아니라, 오래 유지해야 하는 외부 계약으로 보는 관점을 먼저 세웁니다. 그래야 이후 글에서 다룰 REST, 리소스, 상태 코드, 문서화 원칙이 한 흐름으로 연결됩니다.먼저 던지는 질문API는 정확히 무엇이며, 왜 시스템의 외부 계약이라고 부를까요?라이브러리 API와 웹 API는 무엇이 같고 무엇이 다를까요?좋은 API라고 부르려면 어떤 조건을 갖춰야 할까요?큰 그..