1. 들어가며2편에서 만든 MovieFlix API는 기능적으로 완벽합니다. 영화를 조회하고, 만들고, 수정하고, 삭제할 수 있죠.하지만 이대로 인터넷에 배포하면 5분 만에 망합니다.보안: 누구나 DELETE /movies/1을 호출해서 영화를 다 지워버릴 수 있습니다. 😱성능: 영화가 100만 개가 되면 GET /movies 요청 한 번에 서버가 멈춥니다.신뢰성: 코드를 수정했는데 기존 기능이 잘 되는지 매번 손으로 확인할 순 없죠.3편에서는 이 API를 '현업 수준'으로 끌어올리는 필수 요소들을 다룹니다. 2. 보안 (Security)API 보안의 핵심은 "너 누구야?(인증)"와 "너 이거 할 수 있어?(인가)"입니다. 2-1. 인증(Authentication)과 JWTREST API는 '무상태(..

1. 들어가며지난 1편에서 우리는 'MovieFlix(영화 스트리밍)' 서비스의 API를 설계했습니다.URI: /movies행위: GET, POST, PUT, DELETE규칙: 명사형 URI, 적절한 상태 코드이제 이 설계도를 들고 공사장에 왔습니다. 오늘 사용할 도구는 Python FastAPI입니다."왜 Django나 Flask가 아니고 FastAPI인가요?"라고 묻는다면, API 개발에 있어서만큼은 FastAPI가 압도적으로 편리하고 빠르기 때문입니다. 2. 왜 FastAPI인가?짧고 굵게 3가지만 기억하세요.빠르다 (High Performance): NodeJS나 Go에 비견될 만큼 빠릅니다. (Starlette + Pydantic 기반)쉽다 (Easy): 파이썬의 타입 힌트(Type Hint)를..

1. 들어가며프론트엔드(FE)와 백엔드(BE)가 협업할 때 가장 많이 하는 말이 있습니다."API 나왔나요?", "API 명세서 좀 주세요."API를 단순히 "DB에서 데이터 꺼내서 화면에 뿌려주는 기능" 정도로 생각하면, 나중에 유지보수 지옥이 펼쳐집니다."잘 짠 API"는 개발자 간의 명확한 약속(Contract)이자, 시스템의 얼굴입니다.API가 엉망이면 FE 개발자는 "이거 에러가 왜 나요?"라고 하루 종일 되묻고, BE 개발자는 "아, 그거 스펙 바꿨는데..."라며 땀을 흘리게 되죠.이번에는 API의 정석, 특히 현업 표준인 RESTful API를 어떻게 설계해야 '잘 짰다'는 소리를 듣는지 완벽하게 정리해 드립니다.2. API의 정의: (메뉴판과 점원)API (Application Progra..