HTTP 웹 지식 - HTTP API를 만들어보자

📌 김영한 님의 "모든 개발자를 위한 HTTP 웹 기본 지식" 강의 듣고 정리

 

📍HTTP API를 만들어보자

 

*API URI설계 예시 (이게 좋을 URI 설계일까?)

회원 목록 조회	/read-member-list
회원 조회	/read-member-by-id
회원 등록	/create-member
회원 수정	/update-member
회원 삭제	/delete-member

No!

 

API URI에서 가장 중요한 건 리소스 식별이다.

 

리소스란 무엇일까?

회원을 조회하고 수정하는 것이 리소스가 아니라 "회원"이라는 개념자체가 리소스이다. 

그럼 이걸 어떻게 식별할 까?

행위을 배제하고 "회원"이라는 리소스만 식별하여 URI에 매핑하면 된다. 

 

리소스 식별과 URI 계층 구조 활용해 다시 설계해보자

(* 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용을 권장하고 있다 (member -> members))

회원 목록 조회	/members
회원 조회	/members/{id}
회원 등록	/members
회원 수정	/members/{id}
회원 삭제	/members/{id}

???? 그럼 똑같은 것이 4개나 생기게 된다. 구분이 안되는 데 이때 이를 구분하게 하는게 바로 HTTP 메서드이다.

URI는 리소스만 식별하고 행위는 모두 HTTP 메서드로 구분하게 된다. (리소스는 명사, 행위는 동사)

 

 

📍HTTP 메서드 - GET, POST

HTTP 메서드라는 건 클라이언트가 서버에게 요청할 때 기대하는 행동이다.

주로 사용되는 메서드에 대해 미리 간략하게 보자면

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용
• PUT : 리소스를 대체, 해당 리소스 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제

기타 메서드들도 보면

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

이 있다.

 

* GET

• 리소스 조회 (path에 있는 자원을 주세요!)
• 검색 등으로 서버에 전달하고 싶은 데이터는 query(query parameter, query string)를 통해 전달한다.
• 메시지 바디를 사용해서 데이터를 전달할 수도 있지만, 지원하지 않는 곳이 많아 권장하지 않는다

GET /members/100
Host: localhost:8080

서버는 이 메시지를 받으면 /members의 100번을 달라는 말로 해석하여 처리하여 아래 처럼 Response 메시지로 보내게 된다.

HTTP/1.1 200 OK
Content-Type: application/json
Content-length: 34

{
   "username" : "young",
   "age" : 20
}

 

* POST

• 요청 데이터를 처리
• 클라이언트는 메시지 바디를 통해 서버로 요청 데이터를 전달
• 서버는 요청 데이터를 처리 (메시지 바디를 통해 들어온 데이터를 처리하는 모든기능 수행)

POST /members HTTP/1.1
Content-Type: application/json

{
    "username" : "young",
    "age" : 20
}

응답 (members 100번에 해당 자원이 신규 등록되었다)

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100

{
    "username" : "young",
    "age" : 20
}

 

요청 데이터를 어떻게 처리한다는 뜻일까?

POST 메서드는 요청 데이터를 어떻게 처리할지 리소스 URI에 리소스마다 따로 정한다. (정의하기 나름)

크게 묶어보자면

• 서버가 아직 식별하지 않은 새 리소스 등록(조회)
• 요청 데이터 처리 (데이터 생성, 수정 외에도 프로세스 처리 경우도 있음)
• 다른 메서드로 처리 애매한 경우 (GET 메서드를 허용하지 않는 경우도 있음)

 

📍HTTP 메서드 - PUT, PATCH, DELETE

 

* PUT

• 리소스 대체 (리소스가 있다면 완전히 대체, 없다면 생성)
• 클라이언트가 리소스를 식별
  • Post는 그냥 /members 에서 끝났다면 Put 경우 /members/100 으로 구체적인 리소스 경로를 식별

PUT /members/100 HTTP/1.1
Content-Type: application/json

{
   "username" : "old",
   "age" : 50
}

서버에 해당 리소스 없으면 추가, 있으면 해당 값으로 대체한다.

/members/100 의 기존값	/members/100 의 변경값	/members/100 의 결과값
{     "username" : "young",     "age" : 20 }	{    "username" : "old",    "age" : 50 }	{    "username" : "old",    "age" : 50 }

이때 완전히 대체한다는 말을 주의해야 한다. 

기존 값 가운데 일부만 변경하고 싶어 PUT을 사용하면

/members/100 의 기존값	/members/100 의 변경값	/members/100 의 결과값
{     "username" : "young",     "age" : 20 }	{    "age" : 50 }	{    "age" : 50 }
	나이만 바꿀래!	😱 ??????

이런 결과가 나온다. 왜냐면 일부 변경이 아니라 완전 대체이기 때문. 기존 걸 지워버리고 바꿔주려는 값으로 대체해버린다.

위와 같은 의도로 사용하고 싶다면 PATCH를 이용하면 된다.

 

* PATCH

• 리소스 부분 변경

PATCH /members/100 HTTP/1.1
Content-Type: application/json

{
   "age" : 50
}

/members/100 의 기존값	/members/100 의 변경값	/members/100 의 결과값
{     "username" : "young",     "age" : 20 }	{    "age" : 50 }	{    "username" : "young",    "age" : 50 }
	나이만 바꿀래!	😊👍

+ PATCH가 지원이 안된다면 POST사용!

 

* DELETE

• 리소스 제거

DELETE /members/100
Host: localhost:8080

 

📍HTTP 메서드의 속성

 

* 안전 (Safe Methods)

• 호출해도 리소스를 변경하지 않는다. (안전은 해당 리소스만 고려함)

* 멱등 (Idenmpotent Methods)

• 한번 호출하든 두번 호출하든 100번 호출하든 결과가 똑같다. 
• 멱등 메서드 ("같은 데이터, 같은 파일에 대한 같은 요청"을 할때를 생각해볼것)
  • GET : 한 번 조회하든, 두번 조회하든 같은 결과를 조회
  • PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다
  • DELETE : 결과를 삭제 여러번 삭제해도 결국 삭제되는 같은 결과가 나온다
  • POST ? POST는 멱등이 아니다. 같은 요청을 해도 때마다 프로세스를 진행할 수도 있어 중복이 될 수 있기 때문

+ 멱등성 (idempotent) 

멱등성의 멱(冪)은 거듭제곱이란 뜻이 있으며 등(等)은 같다는 뜻을 가지고 있다. 

거듭해도 같다는 뜻으로 수학에서는 연산을 여러번 적용하더라도 결과가 달라지지 않는 성질을 의미하며, 웹에서는 동일한 요청을 한 번 보내는 것과 여러번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태에도 동일하게 남을 때, 해당 HTTP 메소드가 멱등성을 가졌다고 한다.

 

멱등이란 개념이 왜 필요할까?

자동 복구 메커니즘에 사용이 가능하다. 

- 서버가 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는지 판단의 근거

 

어? 그럼 재요청 사이에 외부에서 그걸 바꿔버린다면 결과가 달라질텐데?

멱등은 외부요인까지 고려하지 않는 개념이다. 내가 동일한 요청을 했을때 만을 판단

 

* 캐시가능 (Cacheable Methods)

• 응답 결과 리소스를 캐시해서 사용해도 되는가? 
• GET, HEAD, POST, PATCH 캐시가능 (실제로는 GET, HEAD 정도만 캐시 사용, POST, PATCH는 구현이 쉽지 않기 때문)