HTTP 메서드는 총 9개로 주로 사용하는 메서드가 5개, 그 이외에 기타 메서드가 4개가 있습니다. 이번 게시물에서는 주요 HTTP 메서드에 대해서 구체적으로 다뤄보겠습니다.
✅ GET
이름에서도 알 수 있겠지만 굉장히 직관적으로 조회(Read)의 기능을 한다는 것을 알 수 있습니다.
🤔 그런데 GET으로 처리할 수 있는 "읽기"의 기능은 3개 정도로 나눠볼 수 있습니다.
1. 정적 리소스 2. 특정 조건을 가진 리소스를 검색 (Query String 이용) 3. 특정 조건을 가진 리소스를 검색 (HTML Form 이용)
💠 정적 리소스(데이터) 조회
단순히 리소스의 경로로 파일을 조회할 수 있는 경우
특정 경로에 있는 리소스를 요청하고 반환 받는 가장 기본적인 기능입니다.
💠 특정 조건을 가진 리소스를 검색 (Query String 이용)
조회를 한다는 개념은 똑같지만, 특정 조건으로 조회를 하고 싶은 경우는 어떻게 해야 할까요?
만약 리소스 URL만을 가지고 조회를 할 수 있다면 위의 정적 리소스 조회를 하면 되지만 그 이외에 추가적인 조건을 전달을 하고 싶을 경우 Query String이나 HTML Form을 사용할 수 있습니다.
그중 첫번째 예시인 Query String입니다.
GET 메서드의 Body는 당연히 없기 때문에 요청 라인에 정보를 담아서 주게 됩니다.
💠특정 조건을 가진 리소스를 검색 (HTML Form 이용)
폼을 통해서 정보를 받아서 GET으로 날려주게 되면 Query 스트링과 유사하게 전달하는 정보가 요청 라인에 포함되게 됩니다. GET은 Body가 없으니까요 😀
⭐ 하지만 꼭 명심해야 하는 점은 POST처럼 정보를 넘겨줄 수는 있지만, BODY가 아닌 요청 라인에 추가되게 되며 조회를 하기 위한 정보가 넘어간다는 점입니다.
공식 스펙과 구체적인 사항들을 참고하고 싶다면 아래 요약본도 봐주세요.
참고(공식 문서 요약입니다 넘기셔도 좋아요) :
💠 기본 개념
- GET 메서드는 특정 리소스의 현재 상태를 요청하고, 그에 대한 표현(representation)을 전송받는 데 사용됩니다. - 요청 성공 시 서버는 200 (OK) 상태 코드와 함께 리소스의 현재 표현을 반환합니다.
여기서 표현(Representation) 이란 그냥 요청한 리소스를 다른 말로 했다고 생각하시면 됩니다. 요청을 하면 리소스를 HTML이나 JSON과 같은 형식으로 반환해 준다는 내용입니다. 💠 리소스와 표현의 관계
- GET 요청은 URI를 기반으로 리소스 표현을 식별하여 반환하며, 이는 해당 URI가 가리키는 **“동일성(sameness)”**을 보장합니다 - 리소스는 원격 파일의 경로와 동일시되기 쉽지만, 반드시 그렇지는 않습니다. 리소스는 데이터베이스, 콘텐츠 트리, 또는 외부 정보 시스템을 연결하는 게이트웨이 등 다양한 방식으로 구현될 수 있습니다.
URL는 리소스를 식별하는 주소일 뿐 어떤 형식의 파일인지는 관여하지 않는다는 뜻입니다. 다만 같은 URL은 항상 동일한 리소스를 반환해준다는 뜻입니다.
💠 범위 요청 (Range Request) - 클라이언트는 요청 헤더에 Range필드를 포함하여 리소스의 특정 부분만 요청할 수 있습니다.
💠 GET 요청의 제한 사항 (Get 이 본문이 없는 건 다들 아시죠..!?)
- GET 요청은 기본적으로 **본문(body)**을 포함하지 않습니다. - 본문을 포함하는 GET 요청은 표준화되지 않았으며, 일부 서버는 이를 **요청 스머글링 공격(Request Smuggling Attack)**으로 간주하여 연결을 종료할 수 있습니다. - 예외적으로, 본문을 허용하는 서버와의 사전 합의가 있는 경우에는 사용 가능합니다.
💠 캐싱(Caching)
- GET 요청에 대한 응답은캐싱 가능하며, 이후 동일한 요청(GET 또는 HEAD)에 캐시 된 응답을 사용할 수 있습니다. - 단,Cache-Control헤더에 따라 캐싱 동작은 달라질 수 있습니다.
200번대 응답과 GET은 항상 밀접한 관련이 있는 만큼 GET도 캐싱과 관련된 기능이 있습니다.
💠 보안과 민감 정보
- GET 요청에서 사용자 입력으로 URI를 생성하는 경우, URI에 민감한 정보가 포함될 수 있습니다. 예: URL 쿼리 문자열에 암호나 개인정보가 포함되는 경우. - 이런 경우:데이터를 필터링하거나 변환하여 민감 정보를 제거. 민감 정보가 노출되면 안 되는 상황에서는 POST 메서드 사용을 고려.
URL은 노출되기 쉬움 브라우저 기록, 북마크, 로그 파일, 캐시 등에서 URL이 저장됩니다. 결과적으로, 쿼리 문자열에 포함된 데이터가 쉽게 노출될 수 있습니다. ex) https://example.com/search?username=john&password=1234 GET은 Body가 없기 때문에 url에 필요 정보를 넘기게 되는데요... 때문에 발생하는 보안적 문제가 있을 수 있습니다.
💠서버 구현의 자유로움
- GET 요청에 대한 응답 표현은 서버의 내부 구현 방식에 따라 다양하게 결정됩니다. - 서버는 파일을 직접 반환하거나, 요청을 처리하여 생성된 결과물을 반환할 수 있습니다.
✅ POST
POST는 등록한다 보다는 조금 심오한 의미를 가지는데요. 저 같은 경우는 " 등록 또는 데이터를 넘겨주는 메서드" 정도로 생각하고 있습니다.
🤔 그래서 POST가 정확히 뭔데?
아직 GET을 제외한 다른 메서드는 다루지 않았는데요.. PUT도 있기는 하지만, 많이 사용하는 메서드 중에서 Body에 정보를 제대로 담아서 넘겨줄 수 있는 건 POST 밖에 없습니다.
결국 좀 복잡한 일을 처리해야 한다면 POST를 사용하게 될 수밖에 없어요. "애매하면 POST"라는 말이 괜히 있는 게 아닌 것 같죠? 아무래도 정보를 담아서 넘겨주는 작업 중 무언가 등록을 하는 경우가 많아서 POST를 등록과 관련된 메서드라고 흔히 생각합니다.
하지만, 조금 더 시야를 넓혀서 "데이터를 담아서 넘겨준다"라고 이해하시는 것을 추천합니다.
💠 POST의 기능 예시 1. HTML 양식에 입력된 필드로 회원 가입 주문 2. 게시판, 글쓰기, 그리고 댓글 달기 3. 서버가 아직 식별하지 않은 새 리소스 생성 4. 기존 자원에 데이터 추가하기 (PATCH의 느낌이 나기도 합니다) 5. 단순 생성 보다 복잡한 프로세스 처리 ex) 결제완료 > 배달 시작 과 같은 상태 변경... 6. 조회이지만 데이터를 넘겨야 하는 경우 ( 언뜻 보면 GET의 역할이지만, POST가 처리해야 할 수도 있습니다!)
POST의 가장 일반적인 예시 두 가지를 보여드리겠습니다.
💠 POST의 Body를 이용해 리소스 등록
여기서 확인해야 할 포인트는,
1. /members의 경로로 POST를 날리면 서버에서 리소스를 생성해 주고 식별자를 서버에서 생성해 준다는 점입니다. 클라이언트가 생성되는 리소스의 ID를 모른 채로 요청을 하고 서버가 반환해주는 식입니다.
이 부분이 PUT과 가장 큰 차이점입니다. PUT은 리소스의 식별자를 클라리언트에서 알고 있어야 하고 POST는 모른 상태로 요청을 하게 됩니다.
2. 식별자를 모른채로 등록을 요청했으니 Location을 통해서 식별자를 확인할 수 있습니다. 이 부분은 201 Created와도 관련된 부분인데 참고하시면 좋습니다🔗
💠 HTML FORM + POST를 이용해 등록
HTML FORM을 이용해 요청을 하면 요청 메시지의 Content Type이 form 인코딩 형태인 것을 확인할 수 있습니다. 또한 multipart/form-data를 통해서 여러 형태의 데이터도 한 번에 보낼 수 있습니다.
참고(공식 문서 요약) :
💠 서버의 응답 처리 - 응답 코드의 의미서버는 POST 요청 처리 결과에 따라 다양한 상태 코드를 반환합니다. 예외: 206, 304, 416 상태 코드는 POST 응답에서 사용되지 않음.
- 리소스 생성 시 201 응답새 리소스가 생성된 경우 서버는 201 (Created) 응답을 보냄. 응답에 Location 헤더를 포함하여 생성된 리소스의 URI를 클라이언트에 전달.
- 리소스 참조로 리디렉션 (303 See Other) 처리 결과가 기존 리소스와 동일한 경우, 서버는 클라이언트를 기존 리소스로 리디렉션 할 수 있음. 장점: 리소스의 URI 제공 및 캐시 공유에 유리. 단점: 추가 요청이 발생할 수 있음.
💠 캐싱 관련 특성 - 캐싱 가능 조건 POST 응답은 명시적 캐싱 정보와 Content-Location 헤더를 포함한 경우에만 캐싱 가능 이 경우, 이후 GET 또는 HEAD 요청에서 해당 응답을 재사용 가능. - POST 요청 자체는 캐싱 불가, POST는 잠재적으로 안전하지 않으므로 이전 POST 응답을 사용해 요청을 만족할 수 없 음.
✅ PUT
리소스를 대체(수정)하는 메서드 (Update)입니다.
만약 요청 메시지에 리소스가 있다면 덮어쓰고, 없다면 새로 생성을 하게 됩니다.
이때 리소스를 덮어쓸 경우 완전히 새로운 것으로 대체됩니다.
🤔 PUT은 POST와 유사한 점이 많지만, 불편한 차이점들이 존재해 대부분 POST를 사용하는데요,
1. 데이터의 경로를 정확히 알고 있어야 한다.
POST 같은 경우는 /members와 같은 경로로 POST등록을 하게 된다면 새로운 리소스를 만들고 경로를 알려주었습니다.
하지만, PUT은 완전히 클라이언트가 식별자를 관리해야 하는데요, 수정 또는 대체를 해야 하기 때문에 정확한 경로를 알고 있어야 하는 것이라고 이해하면 쉽습니다. ex) /members/100으로 PUT을 날리게 되면 리소스가 없을 경우 생성되고 있다면 완전히 대체됩니다.
💠 PUT 예시
100번 멤버가 있는 상태에서 새로운 정보를 보내게 되면 100번 멤버는 새로운 데이터로 대체되게 됩니다.
💠 PUT 주의사항
완전히 대체되기 때문에 위와 같이 특정 필드만 바꾸고자 하는 경우 PUT을 사용하면 문제가 될 수 있습니다!
name: young age: 50 으로 바뀌는 것이 아니라 완전히 대체되기 때문입니다.
공식 문서에는 부분 변경에 대한 내용이 있긴 한데... PATCH를 사용할 것 같긴 하네요.
참고(공식 문서 요약) :
💠PUT 메서드의 주요 특징
1. 리소스 생성 또는 대체 - 리소스 생성 또는 대체리소스가 없는 경우: 201 (Created) 응답으로 리소스 생성 알림. - 리소스가 있는 경우: 200 (OK) 또는 204 (No Content) 응답으로 성공 알림.
2. 요청 본문의 일관성 검증 - 서버는 PUT 요청 본문이 대상 리소스의 제약 조건과 일치하는지 확인해야 함. - 일치하지 않을 경우 - 요청 본문을 변환하거나 리소스 설정을 변경하여 일치시킴 - 409 (Conflict) 또는 415 (Unsupported Media Type) 상태 코드로 거부.
3. 헤더와 상태 관리 - PUT 요청에서 처리되지 않는 헤더는 무시. - 변환 없이 저장된 경우에만 ETag 또는 Last-Modified와 같은 검증 필드를 포함 가능.
예시 - 헤더 무시: PUT 요청에서 Authorization 헤더를 포함할 수 있지만, 서버는 이를 무시하고 요청 본문에 포함된 데이터를 처리할 수 있습니다. - 검증 필드 포함: PUT 요청이 변환 없이 서버에 저장되었을 때, 서버는 ETag와 같은 검증 필드를 통해 요청 본문이 그대로 저장되었음을 알릴 수 있습니다.
결론적으로, 서버는 처리되지 않는 헤더를 무시하고, 요청이 변환 없이 저장될 경우 검증 필드를 통해 데이터 무결성을 보장할 수 있습니다.
4. 캐싱 - PUT 요청의 응답은 캐싱되지 않음. - 성공적인 PUT 요청은 기존 URI와 관련된 캐시를 무효화함.
💠PUT의 특수 상황 1. 리디렉션 - 대상 리소스가 이동된 경우, 서버는 3xx (Redirection) 응답을 반환. - 클라이언트는 새로운 URI로 요청을 보낼지 결정.
2. 다른 리소스에 미치는 영향 - 예: "현재 버전" 리소스를 PUT 요청으로 변경하면, 새로운 버전 리소스가 생성될 수 있고 관련 리소스 간 연결이 추가될 수 있음.
3. 부분 업데이트 (Partial PUT) 일부 서버는 Content-Range 헤더를 사용하여 리소스의 일부만 업데이트 가능.
✅ PATCH
특정 필드를 수정할 때 사용하는 메서드입니다.
🤔 만약 PATCH가 지원되지 않는다면 POST를 사용하면 됩니다!
💠PATCH의 예시
✅ DELETE
이름 그대로 리소스를 제거해 줍니다.
💠DELETE의 예시
참고(공식 문서 요약) :
💠응답 메시지
DELETE 메서드가 성공적으로 처리되면, 서버는 아래와 같은 응답 코드를 보냅니다 - 202 (Accepted): 작업이 진행 중이며 곧 완료될 것으로 예상되는 경우. - 204 (No Content): 작업이 완료되었으며 추가 정보를 제공하지 않는 경우. - 200 (OK): 작업이 완료되었으며 상태를 설명하는 응답 메시지가 포함된 경우.
💠 주의사항
- DELETE 메서드는 콘텐츠를 포함할 수 없으며, 콘텐츠는 의미를 변경하거나 요청의 대상 URI를 바꿀 수 없습니다. - 일부 서버는 DELETE 요청에서 콘텐츠를 거부할 수 있으며, 이로 인해 연결이 종료될 수 있습니다. 따라서 DELETE 요청에는 콘텐츠가 포함되지 않는 것이 권장됩니다.
💠캐시 처리
- DELETE 요청에 대한 응답은 캐시 할 수 없으며, 성공적인 DELETE 요청이 캐시를 통과할 경우 이전에 저장된 모든 리소스 응답은 무효화됩니다.
💠 리소스 삭제 처리
- DELETE 메서드가 성공적으로 처리되었더라도, 서버가 리소스를 실제로 삭제할지 여부는 서버의 구현에 따라 달라질 수 있습니다. 일부 리소스는 보관하거나 비활성화될 수 있습니다.
