바이브 코딩만 하는 사람은 절대 모를 이야기 | REST API의 원래 설계 의도 | 설계 공부하고싶은 사람 모여라
- 대부분의 개발자가 REST API를 HTTP 메서드와 URL 규칙의 단순한 조합으로 오해하며, 원래 설계 의도와는 거리가 먼 "끔찍한 혼종"을 사용하고 있습니다. 🤯
- REST API의 창시자인 로이 필딩은 프런트엔드가 API 문서 없이도 개발할 수 있도록, 응답에 포함된 하이퍼미디어 링크(HATEOAS)를 통해 애플리케이션 상태를 탐색하는 것을 의도했습니다. 📜
- HATEOAS는 프런트엔드가 URL을 직접 하드코딩하는 대신, 백엔드로부터 받은 객체 내 링크 필드를 사용하여 다음 액션을 동적으로 발견하게 하여, 백엔드 URL 변경에도 영향을 받지 않게 합니다. 🔗
- 백엔드는 데이터베이스 구조를 그대로 노출하지 않고, 프런트엔드에 의미 있는 값으로 데이터를 재매핑하고 재포장하여 전달해야 합니다. (예: 내부 ID 대신 사용자 친화적인 값, 상태 코드 대신 명확한 의미) 🎁
- 원래 설계 의도대로 구현하면 프런트엔드와 백엔드의 관심사를 명확히 분리하여, 백엔드 변경이 프런트엔드에 미치는 영향을 최소화하고 시스템의 확장성을 높일 수 있습니다. 🛡️
- 하지만 HATEOAS와 데이터 재포장 등의 원래 설계는 구현 복잡성, 백엔드 작업량 증가, "빨리빨리" 개발 문화, 그리고 풀스택 프레임워크의 등장 등으로 인해 널리 채택되지 못하고 있습니다. ⏱️
- 그럼에도 불구하고, 공용 API나 외부 서비스에 노출되는 API를 개발할 때는 원래 REST API의 정신을 따라 프런트엔드와 백엔드의 관심사를 분리하는 것이 매우 중요합니다. 🌐
- 이 영상의 핵심 인사이트는 REST API의 완전한 구현 여부를 떠나, 프런트엔드와 백엔드의 관심사를 분리하여 확장성 높은 시스템을 설계하는 관점을 제공한다는 것입니다. 💡
- 현재 우리가 사용하는 "REST API"는 사실상 "HTTP API"로 용어를 변경하는 것이 더 적절할 수 있다는 제안도 있습니다. 🏷️