[HTTP] HTTP 메서드

HTTP 메서드

회원 정보 관리 API를 만든다면?

• 회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제

크게 위와 같은 기능들이 필요할 것이다.

URI (Uniform Resource Identifier) 설계

---

인터넷에서 특정 자원을 나타내는 주소 값이다. 해당 값은 유일하나, 응답은 달라질 수 있는 특징이 있다.

 

좋지 않은 API URI 설계

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

 

좋은 API URI 설계

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

 

(1) URI는 리소스를 식별해야한다.

• 회원을 등록, 수정, 조회 기능은 리소스가 아니다.
• 회원이라는 개념이 리소스
• 회원을 CRUD 하는 것을 모두 배제하고 회원이라는 리소스만 식별한다.
  • 회원 리소스를 URI에 매핑

 

(2) URI는 계층 구조로 설계한다.

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

 

(3) 리소스와 행위를 분리한다.

• URI는 리소스만 식별한다.
• 리소스와 행위를 분리한다.
  • 리소스 : 회원
  • 행위 : 조회, 등록, 삭제, 변경
• 리소스는 명사, 행위는 동사
• 행위는 HTTP(GET,POST)로 구분 한다.

 

(4) URI 설계 원칙

• 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다
• URI 마지막 문자로(/)는 포함하지 않는다.
• 하이픈(-)은 URI 가독성을 높이는데 사용한다.
• 밑줄(_)은 사용하지 않는다.
• URI 경로에는 소문자가 적합하다.
• 파일 확장자는 URI에 포함하지 않는다.
• 프로그래밍 언어에 의존적인 확장자를 사용하지 않는다
• 구현에 의존적인 경로를 사용하지 않는다
• 세션 ID를 포함하지 않는다.
• 프로그래밍 언어의 Method 명을 이용하지 않는다
• 명사에 단수형 보다는 복수형을 사용해야 한다.
  • 컬렉션에 대한 표현은 복수로 사용한다.
• 컨트롤러 이름으로는 동사나 동사구를 사용한다.
• 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.
• CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.
• URI Query Parameter 디자인 URI 쿼리 부분으로 컬렉션 결과에 대해서 필터링 할 수 있다.
• URI 쿼리는 컬렉션의 결과를 페이지로 구분하여 나타내는데 사용한다.
• API에 있어서 서브 도메인은 일관성 있게 사용해야 한다.
• 클라이언트 개발자 포탈 서브 도메인은 일관성 있게 만든다.

 

HTTP 메서드

---

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

(기타)

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

1. GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해 전달
• 메시지 바디를 사용해서 데이터 전달 가능 하지만, 지원하지 않은 곳이 많음

2. POST

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
  • 서버한테 데이터를 줄 테니까 요청 데이터를 처리해줘!! )
• 서버는 요청 데이터를 처리 , 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
• POST는 모든 역할을 대신할 수 있지만, 조회 시에는 GET이 더 유리하다.
  • 서버끼리는 서로 약속을 하고 있는데 GET으로 오면 캐싱을 하고, POST는 캐싱하기가 까다롭다.

3. PUT

• 리소스를 대체
• 리소스가 있으면 대체
• 리소스가 없으면 생성
• 쉽게 이야기해서 덮어버림
  • 클라이언트가 리소스 위치를 알고 URI 지정(POST와 차이점)
  • 리소스를 완전히 대체하기 때문에, username, age 필드에서 age만 put 요청하면 username 필드가 없어진다.

 

4. PATCH

• 리소스 부분 변경
• 지원 안 하는 경우가 있는데 POST 쓰면 된당.

 

5. DELETE

• 리소스 제거

 

HTTP 메서드의 속성

 

---

• 안전
• 멱등
• 캐시기능

안전(Safe)

• 호출해도 리소스를 변경하지 않는다. (호출 했을 때 변경 되면 안전하지 않음!)
• 안전은 리소스만 고려함

 

멱등(Idempotent)

• 호출을 여러번 해도 결과는 똑같다.
• 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.

멱등 메서드

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

 

캐시기능(Cacheable)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • 웹 브라우저가 내 응답 결과를 저장할 수 있나, 없나?
• GET, HEAD, POST, PATCH 캐시 가능 (실제로든 GET, HAEAD 정도만 캐시로 사용)
  • 캐싱을 하려면 키가 맞아야 하지만, POST는 바디 안에서 보내기 때문에 구현이 쉽지 않다.

 

---

REFERENCE

인프런 강의 -  HTTP 모든 개발자를 위한 HTTP 웹 기본 지식