들어가며
조회는 무조건 GET 인가? 하면 아니죠. GET은 URL로 전달하기 때문에 길이도 제한되고 너무나 쉽게 개인정보가 노출 될 수 있습니다. “그러면 POST 해야되나?”, “그런데 POST는 서버 쪽에 레코드를 생성하는데 사용하는 것 아닌가?” 생각이 꼬리에 꼬리를 뭅니다. 아직 HTTP 메소드에 대해 정리가 제대로 안 된 거였죠. 이번 포스트에서는 “GET 조회 vs POST 조회” 둘의 용도와 차이점에 대해서 공부한 내용을 정리해보았습니다.
GET
GET 메소드는 리소스를 수정하지 않고 서버에서 정보를 검색하는 데 사용됩니다. 매개변수가 URL에 쉽게 포함될 수 있는 간단한 읽기 전용 쿼리에 사용해야 합니다.
- 리소스 상태는 변경 없음
- 쿼리 매개변수는 길이 제한(일반적으로 약 2,048자)이 있는 URL로 전달
POST
‘POST’ 메서드는 리소스 생성 또는 수정을 포함하여 서버에 데이터를 제출하는 데 사용됩니다. 매개변수가 너무 복잡하거나 민감하여 URL에 포함할 수 없는 복잡한 쿼리에도 사용할 수 있습니다.
- URL의 길이 제한 없이 request body에 데이터 전송
- ‘POST’ 요청에 대한 응답은 일반적으로 캐시 불가능
GET 조회 vs POST 조회
GET 조회
get으로 조회는 다음과 같은 형식으로 할 수 있습니다.
- 카테고리별 간편 상품 검색: GET /api/products?category=electronics
- 제품 세부정보 검색: GET /api/products/{id}
POST 조회
POST로 조회는 다음과 같이 할 수 있습니다.
레코드를 생성하는 POST와 구분하기 위해서 _search 파라미터와 같은 파라미터를 추가할 수 있습니다.
- 복잡한 제품 검색: 가격대, 브랜드, 평점, 가용성 등의 필터를 지정하는 페이로드가 포함된 POST /api/products/_search
- 대량 제품 검색: 자세한 정보를 검색하기 위한 제품 ID 목록이 포함된 페이로드가 포함된 POST /api/products/bulk
HEADER와 BODY에 다음과 같이 필요한 데이터를 넣어서 요청합니다.
POST /Patient/_search
Content-Type: application/x-www-form-urlencoded
name=Smith&birthdate=eq1990-01-01💡 Content-Type 이란?
이것은 클라이언트가 서버로 보내는 요청의 본문이나, 서버가 클라이언트에게 보내는 응답의 본문이 어떤 종류의 데이터인지를 나타냅니다.
다음과 같은 구문을 가집니다.
Content-Type: type/subtypeContent-Type의 종류
Content-Type: application/x-www-form-urlencoded
- 데이터가 텍스트 필드로 구성된 간단한 양식 제출에 사용
- ex) name=John+Doe&age=30&city=New+York
Content-Type: multipart/form-data
- 파일 업로드 또는 파일이 포함된 복잡한 양식 데이터에 적합
- form 제출 시 텍스트 데이터와 함께 파일을 보냄
Content-Type: application/json
- 구조화된 데이터를 전송하기 위해 최신 웹 API에서 자주 사용
- ex) {“name”: “John Doe”, “age”: 30, “city”: “New York”}
Content-Type: application/xml
- 데이터를 계층적으로 구성해야 하는 경우와 XML이 필요한 시스템과의 호환성이 필요한 경우에 사용
- ex)
<person><name>John Doe</name><age>30</age><city>뉴욕</city></person>
Content-Type: text/plain
- 데이터가 일반 텍스트이고 구조화된 데이터로 해석할 필요가 없는 경우에 사용
- ex) ‘간단한 텍스트 데이터’
Content-Type: application/octet-stream
- 파일 형식을 알 수 없거나 다양한 파일 업로드에 자주 사용
- ex) 실행 파일, 이미지 등 바이너리 파일 업로드
application/x-www-form-urlencoded VS application/json
application/x-www-form-urlencoded
name=Smith&birthdate=eq1990-01-01application/x-www-form-urlencoded에서는 일반적으로 키-값 쌍 내에서 논리 연산(AND, OR)의 직접 구현이 지원되지 않습니다. 요청 데이터를 구문 분석한 후 서버 측 논리에서 논리 작업을 처리해야 합니다.
다음과 같은 상황에서 application/x-www-form-urlencoded를 사용합니다.
- 간단한 양식 데이터: 복잡한 조건이 없는 양식 제출과 같은 간단한 키-값 쌍에 가장 적합합니다.
- 레거시 시스템: 이전 시스템 및 웹 양식과의 호환성을 위해 종종 사용됩니다.
application/json
‘Content-Type’으로 ‘application/json’을 사용하면 데이터가 JSON 형식으로 전송되므로 더 복잡하고 중첩된 데이터 구조를 지원합니다.
이는 논리 연산을 포함하는 데 더 좋음
{
"conditions": [
{ "field": "name", "operator": "eq", "value": "Smith" },
{ "field": "birthdate", "operator": "eq", "value": "1990-01-01" }
],
"logic": "AND"
}다음과 같은 상황에서 application/json를 사용합니다.
- 복잡한 데이터 구조: 단순한 키-값 쌍 이상이 필요한 복잡하고 중첩된 데이터 구조를 보내는 데 선호됩니다.
- 논리 연산: 페이로드 내에 직접 논리 조건을 포함하는 데 적합합니다.
- API 및 최신 애플리케이션: 구조화되고 쉽게 구문 분석할 수 있는 데이터가 필요한 최신 API 및 웹 애플리케이션에서 일반적으로 사용됩니다.
GET, POST 차이 정리
- POST 요청은 일반적으로 브라우저나 프록시에 의해 캐시되지 않으므로 민감한 데이터가 캐시에 저장될 위험이 줄어듦
- GET 요청은 브라우저와 중간 프록시에 의해 캐시될 수 있음
| 측면 | GET | POST |
|---|---|---|
| 용도 | 일반적으로 데이터 검색(안전한 작업)에 사용 | 리소스를 생성 또는 업데이트하고 서버 상태를 수정하는 작업에 사용 |
| 캐싱 | 일반적으로 브라우저와 프록시에 의해 캐시 됨 반복 요청에 대한 성능 향상 | 기본적으로 캐시되지 않음 데이터가 캐시에 저장되지 않으므로 더욱 안전 자주 변경되거나 민감한 정보가 포함된 데이터에 적합 |
| URL 길이 제한 | URL 길이 제한이 적용됩니다(대부분의 브라우저에서 약 2000자) 매우 긴 쿼리 문자열로 인해 문제가 발생 | 데이터는 URL이 아닌 바디로 전송 바디 길이 제한이 없음. 대용량 데이터에 적합 |
참고하면 좋은 글
