REST를 "JSON API" 정도로만 외워 왔는지, 아니면 자원 식별·메서드 의미·무상태성 같은 제약과 그 제약이 만드는 장단점을 풀 수 있는지를 가른다.
REST는 자원(Resource)을 URI로 식별하고, 그 자원에 대한 행위는 HTTP 메서드(GET·POST·PUT·DELETE)로 표현하는 통신 스타일이다. 무상태성·계층화·표현(Representation) 분리·캐시 가능성 같은 제약을 받아들이는 대신 클라이언트와 서버를 느슨하게 묶을 수 있다. JSON 같은 자기 서술적 포맷이 많이 쓰여 다양한 플랫폼이 같은 API를 사용하기 쉽다. 다만 한 화면이 여러 자원을 동시에 필요로 할 때 요청이 많아지고, 행위 중심 도메인(트랜잭션 실행, 명령형 작업)은 자원 표현으로 비틀어 맞추다가 부자연스러워지는 한계가 있다.
동사 중심 엔드포인트를 자원 중심으로 정리하며 캐시·멱등성 의도를 회복한 경험이 있다면 "REST의 진짜 이득" 이야기로 풀어낼 수 있다
N+1 요청 문제를 BFF나 GraphQL로 푼 경험이 있다면 REST의 한계와 보완 전략 사례로 보여 줄 수 있다
응답 스키마 변경 시 버전 관리·하위 호환을 어떻게 가져갔는지 경험이 있다면 "공개 API의 약속" 관점으로 일반화할 수 있다
REST 스캐폴딩을 빠르게 만들었다가 자원 경계를 잘못 잡아 엔드포인트가 점점 늘어난 경험이 있다면 설계 전 경계 정의의 중요성으로 이어갈 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.