HTTP 메서드와 상태코드

오늘은 

지난번, 직접 Insomnia로 테스트해보며 HTTP 메서드가 기능은 포함하지 않는다는 사실을 알게 되었습니다. 
같은 의미로 상태 코드 또한 어떤 기능도 지니지 않으며 표준을 지키지 않더라도 백엔드 동작에는 아무 문제가 없을 것입니다. 
그렇다면 왜 메서드와 상태 코드를 올바르게 작성해야 하는 것일까요


1. 컨벤션에 맞지 않는다.
- 컨벤션이 맞지 않으니 클라이언트와 서버가 서로 생각하는 동작이 다르게 될 확률이 있습니다. 이는 서비스 자체에 결함을 초래할 수 있습니다. 예를 들어 PATCH를 사용해도 충분한 API에서 PUT으로 작성하게 된다면 매번 해당 데이터 전체를 덮어쓰는 작업을 표준으로 두기 때문에 트래픽 낭비가 생길 수 있습니다. 

 

2. 상태 코드의 쓰임

- 같은 맥락에서 올바르지 못한 상태 코드를 전달했을 때도 생각해 볼 수 있습니다. 클라이언트는 서버로부터 반환된 상태 코드를 보며 다음 요청을 진행할 겁니다. 만약 만료된 액세스 토큰을 재발급 받는 API 요청을 보낸다면, 서버로부터 액세스 토큰이 만료되었다는 에러 메세지와 상태 코드로 응답을 받은 뒤에 요청을 진행할 것입니다. 

 

3. RESTful API

- 결국 메서드와 상태 코드를 제대로 작성하는 것은, API를 RESTful하게 작성하는 과정입니다. 다른 개발자가 API의 내용만 보고도 

(URL, 메서드 등) 이 API가 어떤 식으로 동작하는지 알 수 있게끔 작성하는 게 중요합니다. 

 

HTTP 공부를 하다 보면 결국 REST로 이어지게 되는 것 같습니다. 

자주 이야기되는 주제인 만큼 RESTful 하게 API를 작성할 수 있도록 신경 써야겠습니다. 

아래는 제가 참고했던 포스트의 내용입니다. 

리소스를 표현한 상태라는 것의 의미
앞서 이야기했듯이 REST가 이야기하는 Representation State라는 단어는 원본 리소스를 표현한 상태라는 것을 의미한다.
원본 리소스는 데이터베이스에 저장된 하나의 로우로써 존재하지만 클라이언트에게 이걸 그대로 넘겨줄 수는 없으니 서버가 원본 리소스를 읽어와서 적당한 상태로 표현해주는 것이다.
그리고 이 적당한 상태에 대한 힌트는 HTTP 요청 헤더나 응답 헤더에 전부 나와있다.

GET https://iamserver.com/api/users/2
Host: iamserver.com
Accept: application/json

위에서 예시로 들었던 상황에서 클라이언트는 서버에게 2번 유저의 리소스를 요청하며 요청 헤더의 Accept라는 키에 application/json이라는 값을 담아서 보냈다.
클라이언트가 서버에게 “2번 유저의 상태를 json으로 표현해줘”라는 요청을 보낸 것이다.
만약 클라이언트가 application/json이 아닌 application/xml을 담아보냈고, 서버가 XML 포맷의 표현을 지원하도록 작성되어있다면 2번 유저의 리소스는 XML 형태로 표현되어 내려왔을 것이다.
그리고 서버는 응답 헤더에 Content-Type이나 Content-Language와 같은 키를 사용하여 이 리소스가 어떤 방식으로 표현된 상태인지 클라이언트에게 알려주고, 클라이언트 또한 이 정보를 읽은 후 각 컨텐츠 타입에 맞게 정보를 파싱한다.
즉, 클라이언트는 2번 유저의 리소스를 받은 것이 아니다. JSON으로 표현된 2번 유저 리소스의 현재 상태를 받은 것이다. 이처럼 REST는 클라이언트와 서버가 리소스의 타입이나 원하는 언어 등을 사용하여 자원을 자유롭고 명확하게 표현할 수 있는 것에 집중한다.

- https://evan-moon.github.io/2020/04/07/about-restful-api/ 

 

더불어

- 팀스파르타 Node.js 이성일 튜터님 

- 팀스파르타 Node.js 강창민 튜터님