HTTP API, Method(메서드)

2023.06.23 - [Http] - HTTP

HTTP

우선 HTTP가 무엇이고 어떤 특성을 가지는지에 대해서 알아보고 싶다면 앞선 글을 읽어주길 바란다.

---

우리가 HTTP나 여러 인터넷의 진행 과정 등을 공부하는 이유는 대게 회사에 입사하여 해당 직무를 해결하기 위함이라고 생각한다.

그렇다면, 우리가 HTTP에 관해서 공부를 한 뒤 회사에 입사하였다고 가정해보자. 그리고 개발팀 상사가 본인에게 HTTP API를 만들어보라고 한다면 당신은 어떻게 할 것인가?

---

API URI를 설계해보지 않은 사람들은 쉽사리 이를 설정하기 어려움이 있을 것이다.

좋은 URI 설계는 어떻게 해야할까?

결론부터 말하자면, 제일 중요한 것은 우리가 중요하다고 생각하는 리소스의 식별이다.

여기서 리소스의 식별은 어떻게 하는 것일까? 예시를 들어보자.

우리가 회원을 등록하고 수정하는 API URI를 만들 때, 등록과 수정이 리소스가 아니다.

여기서 리소스는, 회원이라는 개념 자체이다.

결국 이 리소스 식별의 과정을 거쳐 URI는 계층 구조를 활용할 수 있게 된다.

예를 들어, 회원 목록 조회는 /members 가 될 수 있고 회원 조회, 수정, 등록, 삭제는 /members/{id} 가 될 수 있다.

그렇다면, 여기서 이들을 어떻게 구분할 수 있는거지?? 라는 의문이 드는게 당연하다.

이때, 필요한 것이 HTTP Method 이다.

리소스를 식별하여 계층 구조를 만든 후에, 해당 리소스와 행위를 분리하는 것이다.

다시 한번 말하자면, 조회, 수정, 등록, 삭제 와 같은 행위를 회원 이라는 리소스와 구분한다는 말이다.

해당 행위를 HTTP에는 Method를 통해 표현할 수 있도록 만들어 놓았다.

 

HTTP 메서드 종류

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용된다.
• PUT : 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성한다.
• PATCH : 리소스의 부분 변경에 사용
• DELETE : 리소스 삭제

---

기타 메서드

• HEAD: GET과 동일하지만 메세지 부분을 제외, 상태 라인과 헤더만 반환한다.
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명, CORS에서 주로 사용
• CONNECT: 대상 리소스로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트를 수행

[ CORS는 (Cross-Origin Resource Sharing) 로 더 자세히 알고 싶은 분들은 따로 알아보는걸 추천한다.]

---

GET

• 리소스를 조회
• 서버에 전달하고자 하는 데이터는 query를 통해 전달한다. [ ?data&data2 ... 형태]
• 메시지 바디를 사용하여 데이터를 전달할 수 있지만, 권장하지 않음(지원이 안되는 곳이 많음)

클라이언트에서 회원에서 members/100으로 되어있는 데이터를 조회하는 경우이다.

해당 데이터를 서버측에서 찾아서 응답 메세지를 만들어서 보내는 경우이다.

클라이언트는 위의 응답 데이터를 받게 되는 것이다. 메세지 바디 부분에는 원하는 데이터가 json형태로 들어있다.

POST

• 요청 데이터를 처리
• 메세지 바디를 통해 서버로 요청 데이터를 전달한다.
• 서버는 요청 데이터를 처리 → 메세지 바디로 들어온 데이터를 처리하는 모든 기능을 수행
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용한다.

위와 다른 점이 보일 것이다. 조회 시에는 /members/100 으로 되어있지만 POST는 데이터 처리이기 때문에 없다.

위와 같이 메세지를 서버단으로 보내면 서버에서 임의로 번호를 할당해서 데이터를 members 리소스에 등록하는 것이다.

위와 같이 서버에서 클라이언트로 보내는 응답 데이터에 Location 정보를 넣어서 처리를 요청한 데이터의 리소스 위치를 알려준다.

[ 응답 데이터에 있는 200, 201 와 같은 건 HTTP 상태 코드라고 알고 있으면 된다. ]

POST 메서드는 여러 경우에 사용될 수 있는데 그 경우마다 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다.

→ 따로 정해진 것이 없기 때문이다.

PUT

• 리소스를 대체 ( 리소스가 없으면 생성 ) → 덮어쓰기
• ★클라이언트가 리소스를 식별 → 클라이언트가 리소스 위치를 알고 URI를 지정해야 함. ( POST와 차이점 )

리소스가 있는 경우에는 변경 사항이 있으면 변경이 된 것으로 덮어쓰기가 된다. → 리소스 대체

/memebers/100 에 username: "old", "age: 50 이라는 데이터가 신규 생성됨. → 신규 리소스 생성

 

※주의

위와 같이, 필드를 다 적어주지 않으면 덮어쓰기이기 때문에 해당 필드는 삭제되어버린다.

만약에 해당 age 부분만을 바꾸고 싶다면, 필드를 다 적고 PUT으로 해도 되지만 더 편한 방법은 PATCH를 사용하는 것이다.

PATCH

• 리소스 부분 변경

위와 같이 PATCH 방식으로 age: 50을 보낸다면, members/100에 age 필드가 50으로 변경되며, username 필드는 변경되지 않는다.

DELETE

• 리소스 제거

DELETE를 사용하여 리소스를 제거,삭제할 수 있다. 위와 경우에는 /members/100 리소스를 제거하는 상황이다.

---

HTTP 메서드의 속성

• 안전( Safe Methods )
• 멱등( Idempotent Methods )
• 캐시가능( Cacheable Methods )

---

안전 Safe

→ 호출해도 리소스를 변경하지 않는다.

호출을 계속해도 해당 리소스가 변경되지 않는 메서드를 안전 특성을 가졌다고 한다.

멱등 Idempotent

→ 호출을 계속해도 결과가 똑같다.

한번 호출하든 두번 호출하든 100번 호출하든 결과가 같다.

 

멱등 메서드

• GET : 조회를 많이 해도 같은 결과가 조회됨.
• PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
• DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 동일
• ★POST : 멱등이 아니다!! 두번 호출하면 같은 결제가 중복해서 발생할 수 있다.

[ 멱등은 자동 복구 메커니즘에 활용된다. ]

캐시 가능 Cacheable

→ 응답 결과 리소스를 캐시해서 사용해도 되는가?

GET, HEAD, POST, PATCH 방식이 캐시 가능이다.

실제로는 GET, HEAD 정도만 캐시로 사용한다. → 왜냐하면, POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지가 않다.

---

HTTP 는 어디에서나 사용되고 필수로 알아야 할 지식이기에 모두 제대로 학습하길 바란다!

다음 게시글에는 HTTP 메서드를 활용하여 어떤 상황에, 어떻게 적용할지에 대해서 설명해보겠다.