🚀 검색 API: GET vs POST 방식 비교

“검색(조회)은 당연히 GET 아니야?” 라고 생각하는 것이 REST API의 기본 원칙에 대한 올바른 이해입니다.

그럼에도 불구하고 실무에서 검색 기능에 POST를 사용하는 데에는 몇 가지 현실적인 이유가 있습니다.

✅ 원칙: 검색은 GET이 맞습니다

멱등성(Idempotent)을 가지는 단순 조회 기능은 GET 메서드를 사용하는 것이 RESTful API의 원칙에 가장 부합합니다.

GET 방식의 장점

• 멱등성: 여러 번 호출해도 결과가 동일한 특성. “선사시대”를 100번 검색해도 항상 같은 결과가 나옵니다.
• 캐싱: GET 요청은 브라우저나 네트워크 장비에서 캐싱될 수 있어 성능에 이점이 있습니다.
• 북마크 및 공유: URL 자체에 검색 조건이 포함되어 (?q=선사시대) 링크를 북마크하거나 다른 사람에게 공유하기 쉽습니다.

🤔 현실: 왜 POST를 사용할까요?

이론적으로는 GET이 맞지만, 다음과 같은 GET의 한계 때문에 실무에서는 POST를 사용하곤 합니다.

1. 검색 조건이 복잡하고 길어질 때

만약 검색 조건이 단순히 chapterName 하나가 아니라, 여러 필터를 조합해야 한다면 어떻게 될까요?

복잡한 검색 예시

• “선사시대” 챕터 중에서
• “구석기” 또는 “신석기” 시대의 유물 중
• 특정 지역(“연천 전곡리”)에서 발견되었고
• 등록된 지 1년 이내인 데이터

GET 방식의 문제점

URL이 아래처럼 매우 길고 복잡해집니다.

/api/search?chapter=선사시대&type=유물&periods=구석기&periods=신석기&region=연천 전곡리&registeredAfter=2024-10-07...

가독성이 떨어지고 관리하기 어렵습니다.

POST 방식의 해결

동일한 검색 조건을 JSON Body에 담아 보내면 훨씬 구조적이고 명확하게 표현할 수 있습니다.

{
  "chapterName": "선사시대",
  "type": "유물",
  "periods": ["구석기", "신석기"],
  "region": "연천 전곡리",
  "registeredAfter": "2024-10-07"
}

2. URL 길이 제한

문제점

대부분의 브라우저와 웹 서버는 URL의 길이를 약 2000자 내외로 제한합니다.

복잡한 검색 조건이나, 여러 개의 ID 목록으로 검색하는 경우 이 길이를 쉽게 초과할 수 있습니다.

POST 방식의 해결

HTTP POST 요청의 Body는 URL 길이 제한과 무관하므로, 훨씬 더 많은 양의 검색 조건을 안전하게 서버로 보낼 수 있습니다.

3. 보안 및 민감 정보

문제점

GET 요청은 모든 검색 조건이 URL에 그대로 노출됩니다.

이는 브라우저 방문 기록, 웹 서버 로그, 공유된 링크 등에 민감한 정보(예: 주민등록번호, 개인 이름)가 그대로 남을 수 있다는 보안적 약점을 가집니다.

POST 방식의 해결

POST 요청의 Body는 URL에 드러나지 않으므로, 민감한 정보를 담아 검색해야 할 때 훨씬 안전한 방법입니다.

📊 비교 정리

💡 결론

“단순 검색은 GET, 복잡한 검색은 POST”

이번 경우처럼 단순히 chapterName 하나만으로 검색한다면 GET으로도 충분하지만, 앞으로 이 검색 기능이 더 복잡해질 가능성을 염두에 두고 확장성을 위해 POST를 선택하는 것은 매우 실용적이고 현명한 설계 결정일 수 있습니다.