과거의 내가 미래의 나에게
HTTP 학습 (5) - methods 본문
상태코드가 다 끝나지 않았지만 일단 HTTP 메소드에 대해 글을 쓰는 이유는... 프로젝트를 하다가 이번에 같이 작업하시는 백엔드 분이 RESTful한 API를 작성하시기에 이를 사용하다가 REST한 API의 근간이 되는 HTTP 메소드에 대해 얼른 미리 공부해봐야겠다 생각해서 잠시 상태코드를 멈추고 정리를 해본다.
HTTP 메소드란
HTTP에서 사용되는 요청 방법을 나타낸다. 즉 클라이언트가 서버에서 이루어져야 할 동작을 지정하여 요청을 하는 방법이다. 동작에 대한 뚜렷한 의사표시가 있기에 특정 리소스를 서버가 어떻게 다룰지 명확해지기에 웹의 동작을 예측 가능하고 효율적으로 설계할 수 있게 된다.
HTTP 메소드는 총 9개가 존재하지만 자주 쓰이는 것은 5개정도 뿐이다.
1. GET: 리소스를 조회를 요청하는 메서드
서버로부터 리소스를 요청하는 데 사용된다. 해당 메소드는 리소스의 상태를 변경하는 작업없이 단순히 받기만을 요청하는 메소드이기에 리소스 자체에 영향을 주지 않는다.
서버에서 일부 리소스만 불러오고 싶을 때는 서버에 관련된 정보를 보내야하는데, GET 메소드에서는 Query(쿼리)를 이용하여 서버에 관련된 정보를 보낸다.
쿼리는 DB에서 정보를 요청하는 요청문을 의미하는 것으로 데이터를 검색하고 필요한 정보만을 가져올 수 있게끔 한다. 보통 서버로 보내는 URI 뒤에 붙여서 보내게 된다. 아래 예시에서 ? 뒤의 문장이 그 예시이다.
https://example.com/search?name=John&age=30
다만 URI에 쿼리를 붙이게 되면 그 데이터가 그대로 노출되기 때문에 보안이 필요한 정보는 피해야 할 것이다.
쿼리 외에 body를 이용하여 데이터를 전달할 수도 있지만 HTTP 프로토콜 자체에서 권장되지 않는 방법이고 또 서버가 이를 받아주지 않는다면 무시될 수 있기에 body를 이용해야한다면 다른 메소드로 변경하는 것이 나을 것이다.
< 쿼리의 제한은 256글자? >
GET 메소드를 쿼리를 통해 요청할 때 총 URI의 길이는 256글자의 제한이 있다라고 한다. 해당부에 대해 글을 적으려다 좀 더 살펴보니깐 정확히는 제한이 있는 것이 아니어서 관련되어 정리해놓는다.HTTP 규약에는 URI의 길이를 제한한다는 내용은 없고 다만 브라우저마다 최대 길이 제한이 다를 뿐이다. 다만 일부 이전 구현 환경에 대해 동작하지 않을 수 있으므로 255byte를 초과할 때는 유의하라는 말이 적혀있다.
또한 URI를 길게 쓰는 것은 보안면이나 성능면에서 그 활용도가 많이 떨어지기에 쿼리를 마냥 길게 쓰기보단 다른 메소드를 이용하는 것이 나을 것이다.
2. POST: 리소스를 전달하여 전달한 리소스의 처리를 요청하는 메소드
주로 전달된 리소스를 생성하거나 혹은 요청에 맡게 처리하는 데 사용된다. POST는 주로 데이터의 생성/처리에 사용되지만 사실 서버에서 다루기에 따라 모든 동작을 수행 가능한 메소드이다. 실제로 내가 참여한 첫 개발에서는 백엔드의 API는 모두 POST로 이루어져있던 기억이 있다. 모든 동작을 수행가능하기에 좀 애매하다 싶으면 POST 메소드를 사용하는 경우가 많았다.
메시지 바디에다가 처리를 원하는 데이터를 실어보내면 되고 바디에는 따로 제한이 없기에 자유롭게 보내도 되지만 이는 서버의 환경에 따라 달라질 수는 있다.
3. PUT: 리소스의 대체를 요청하는 메소드
리소스를 보내고 해당 리소스가 이미 있다면 업데이트하고 없다면 새로 생성을 요청하는 메소드이다. 여기서의 업데이트는 이미 존재했던 리소스를 완전히 지우고 새로 올린다는 의미로 리소스를 전체적으로 교체 한다는 뜻이다.
클라이언트는 리소스의 존재를 이미 알고있다는 전제이기에, PUT 메소드로 요청을 보낼 때는 리소스의 경로에 대해 같이 알려줘야한다.
POST는 특정 박스에 대한 리소스를 가리키고 PUT은 박스 안에 있는 특정 무언가의 리소스를 가리킨다 생각하면 되겠다.
4. PATCH: 리소스 일부의 수정을 요청하는 메소드
메시지 바디를 통해 리소스에서 변경을 원하는 부분만 보내면 된다. 기능적으로는 PUT과 유사하지만, 완전히 대체되는 PUT과 다르게 기존 데이터의 일부만 변경하게 된다.
예를 들어, 사용자 프로필이 {name: "바삭", mentalAge: 17}으로 구성되어있다 가정하자. 그리고 mentalAge를 27로 수정하고 싶어 바디에 {mentalAge: 27}로 보냈다면, PUT의 경우 데이터 자체가 {name: "바삭", mentalAge: 17}에서 {mentalAge: 27}로 변경되어 버린다. PATCH로 {mentalAge: 27}를 보낸다면 {name: "바삭", mentalAge: 27}로 변경된다.
물론 해당 메소드를 쓰면 무조건 이렇게 처리된다는 것이 아닌 해당 메소드는 이럴 때 쓰도록 하자, 라는 기준이 되어줄 뿐이고 실제로는 서버가 저런식으로 구현이 안되어있으면 다 의미 없기에 API 문서를 잘 봐야할 것이다!!
5. DELETE: 리소스의 제거를 요청하는 메소드
경로에 있는 리소스의 제거를 요청하는 메소드이다. 메시지 바디는 필요로 하지 않고 다만 리소스의 경로만을 필요로 한다. 물론 GET과 비슷하게 body를 이용해서 데이터를 전달은 할 수는 있지만 DELETE 요청의 의미엔 따로 리소스의 존재가 필요없기에 쓸 이유가 없을 것이다.
위의 메소드까지가 주로 사용되는 메소드이고, 아래부터는 잘 쓰이지 않는 메소드에 대해 정리해본디
6. HEAD: 요청한 리소스의 헤더 정보만 반환하는 메소드
GET 메소드와 동일하지만 바디는 리턴하지 않고 상태 줄과 헤더만 반환받는다. 따라서 내용물을 필요로 하는 것이 아니라 리소스의 헤더 정보를 통해 다양한 상태를 확인하는 데 사용된다. 내용물은 오지 않기에 서버의 상태를 빠르게 조회할 수 있다.
7. CONNECT: 요청한 리소스에 대해 양방향 연결을 시작하는 메소드
일반적으로 브라우저가 프록시 서버를 통해 보안 연결을 설정할 때 사용된다고 한다고 하는데, 메소드 중에서 가장 뭐하는지 모르는 녀석이다.
8. OPTIONS: 본격적으로 요청하기 전에 요청이 안전하게 잘 되는지 미리 요청해볼 수 있는 메소드
서버가 어떤 메소드를 지원할 수 있는지 확인할 수 있다. CORS 동작에서 이 메소드가 사용되기도 한다. 좀 더 자세한 내용을 알고 싶다면 해당 블로그를 참고해보자
9. TRACE: 클라이언트가 자신이 보낸 요청이 서버에 어떻게 도달하는지 확인할 수 있는 메소드
클라이언트-서버 간의 Loop Back Test를 진행할 수 있게 도와주는 메소드라고 한다. Loop Back Test는 데이터가 출발하여 다시 자기 자신으로 도착하게끔 하는 것으로 네트워크가 정상적으로 작동하는지 확인하는 용도이다.
오늘은 HTTP 메소드를 먼저 정리해보았고 이를 바탕으로 다음글에는 REST API에 정리하고 또 자주 사용하는 AXIOS에 대해서도 정리하여 이 3개가 어떻게 다르고 정확히 무엇인지 알아보려한다.
참고 문서
- HTTP 메서드 종류 & 요청 흐름 💯 총정리 - https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-HTTP-%EB%A9%94%EC%84%9C%EB%93%9C-%EC%A2%85%EB%A5%98-%ED%86%B5%EC%8B%A0-%EA%B3%BC%EC%A0%95-%F0%9F%92%AF-%EC%B4%9D%EC%A0%95%EB%A6%AC
- HTTP 메서드 정리 (GET, POST, PUT, PATCH, DELETE ...) - https://rachel0115.tistory.com/entry/HTTP-%EB%A9%94%EC%84%9C%EB%93%9C-%EC%A0%95%EB%A6%AC-GET-POST-PUT-PATCH-DELETE