974. RESTful API - 웹 아키텍처 상태 전송 무상태(Stateless) 자원 URI 명시 HTTP 메서드 CRUD 조작 통신 인터페이스 규약 설계 표준

핵심 인사이트: 10년 전엔 서버끼리 데이터를 주고받을 때 규칙이 개판이었다. XML을 덕지덕지 바르고 이상한 명령어(get_user_info_by_id.php)를 쓰느라 코드가 스파게티가 됐다. 웹의 창시자 중 한 명인 로이 필딩(Roy Fielding)이 빡쳐서 헌법을 세웠다. "야! 웹(HTTP)이라는 기가 막힌 시스템을 왜 그따위로 써! 억지로 새 명령어 만들지 마! 모든 데이터(자원)에는 **인터넷 주소(URI)**를 예쁘게 딱 하나씩 부여해! 그리고 그 데이터를 조작하는 건 오직 HTTP의 4가지 동사(GET(조회), POST(생성), PUT(수정), DELETE(삭제))로만 해라!" 전 세계 웹 개발자와 서버들이 말귀를 하나로 통일하게 만든 웹 API 설계의 절대 교과서, RESTful API다.

Ⅰ. REST (REpresentational State Transfer)의 탄생

  • 웹(Web)의 창시자 팀 버너스리가 만든 HTTP 프로토콜의 장점을 극대화하기 위해 탄생한 아키텍처 스타일(설계 철학)입니다.
  • API (Application Programming Interface): 내 앱이 카카오톡 서버에게 "친구 목록 좀 줘!"라고 요청할 때 쓰는 '명령어 소통 창구'입니다.
  • 이 API를 **"REST의 철학(규칙)을 완벽하게 지켜서(RESTful) 아름답게 만들자!"**는 것이 핵심입니다.

Ⅱ. RESTful API의 3대 핵심 규칙 (무조건 암기) 🌟

1. 자원 (Resource)은 명사(URI)로만 표현하라! 🌟

  • 조작하려는 대상(데이터)은 인터넷 주소(URI)로 정확하고 심플하게 찍어줘야 합니다. 동사(행동)가 주소에 들어가면 쓰레기 취급받습니다.
  • ❌ 나쁜 예: http://naver.com/deleteUser?id=5 (URL에 delete라는 동사가 들어감)
  • ✅ 좋은 예 (RESTful): http://naver.com/users/5 (오직 '5번 유저'라는 자원만 명사로 예쁘게 지정함)

2. 행위 (Verb)는 오직 HTTP Method로만 하라! (CRUD 맵핑) 🌟

자원(URI)을 찾았으면, 그 자원을 지지고 볶는 행위는 오직 4대 HTTP 메서드로만 표현해야 합니다.

  • GET (조회, Read): "5번 유저 정보 가져와!" ➜ GET /users/5
  • POST (생성, Create): "새 유저 만들어!" ➜ POST /users (데이터는 본문에 숨겨서)
  • PUT / PATCH (수정, Update): "5번 유저 이름 철수로 수정해!" ➜ PUT /users/5
  • DELETE (삭제, Delete): "5번 유저 탈퇴시켜!" ➜ DELETE /users/5
  • (똑같은 /users/5 라는 주소 하나만 가지고도, 앞에 어떤 메서드(동사)를 붙이냐에 따라 서버가 완벽하게 다르게 동작하는 미니멀리즘의 극치입니다.)

3. 표현 (Representation) - JSON 대통합

  • 서버가 "5번 유저 정보 여기 있어!"라고 답장을 줄 때 옛날엔 무거운 XML을 썼지만, 요즘 RESTful API는 100% JSON (JavaScript Object Notation) 형식(중괄호 덩어리)으로 던져주는 것이 산업 표준(De facto)이 되었습니다.

Ⅲ. 무상태 (Stateless) 통신의 강제 🌟

REST 아키텍처가 클라우드 시대를 지배한 치명적 이유입니다.

  • Stateless: 서버는 클라이언트(폰)의 과거 상태(로그인 여부 등)를 절대 기억하지 않습니다.
  • 클라이언트는 매번 요청(GET)을 날릴 때마다 "저 로그인 한 철수인데요, 5번 유저 주세요"라고 토큰(인증표)을 패킷에 포함해서 쏴야 합니다.
  • 클라우드의 축복: 서버가 고객의 기억(상태)을 뇌(RAM)에 저장하지 않으니 서버가 엄청 가벼워집니다. 트래픽이 폭주해서 카카오 서버를 1대에서 10,000대로 늘려도(Scale-Out), எந்த 서버로 요청이 들어가든 100% 완벽하게 처리됩니다.

Ⅳ. GraphQL, gRPC와의 경쟁

  • RESTful은 완벽하지만, 화면 하나에 유저 정보, 댓글, 좋아요 개수 등 여러 데이터가 필요할 때 서버에 GET 요청을 3~4번 날려야 하는 단점(Over-fetching)이 있습니다.
  • 이를 박살 내기 위해 페이스북은 "그냥 쿼리문 한 줄로 필요한 데이터만 골라서 한 방에 뽑아오자!"며 **GraphQL(478번 문서)**을 만들었고, 구글은 **gRPC(479번 문서)**를 만들어 REST와 경쟁하고 있습니다.

📢 섹션 요약 비유: 옛날 API 시스템은 동네 식당의 '주먹구구식 주문'과 같았습니다. 어떤 손님은 "사장님, 김치찌개 하나 취소요!", 어떤 손님은 "메뉴판에서 3번 빼주세요!" 라며 규칙 없이 아무 말이나 던져서 주방장(서버)이 헷갈려 요리를 망쳤습니다. RESTful API는 이 식당에 완벽한 **'전 세계 공통 키오스크 터치 주문 규칙'**을 세운 것입니다. 1. 메뉴(자원)는 무조건 메뉴판 번호(URI 명사)로만 찍습니다. ("3번 찌개"). 2. 주문 행동(행위)은 무조건 4개의 버튼(GET 보기, POST 주문, PUT 변경, DELETE 취소)만 누를 수 있습니다. "3번 찌개"를 고르고 "DELETE" 버튼을 누르면 군말 없이 주문이 취소됩니다. 전 세계 어떤 개발자가 와도 1초 만에 메뉴판(API)을 쓱 보고 직관적으로 코드를 짤 수 있게 만든 가장 아름답고 규격화된 대화법입니다.