HTTP 메서드 및 URI 설계

본 포스팅은 인프런 김영한 강사님의 "모든 개발자를 위한 HTTP 웹 기본지식 정리" 강의 내용을 정리 및 요약 내용입니다.

URI 설계

• 동사형 보다는 명사형으로
• 따라서 리소스의 개념을 이해하는 것이 좋음
• 예) 회원정보를 조회해라 -> 회원이 리소스
• /get-members-list -> /members
• 참고로 계층 구조상 상위를 컬렉션으로 보고 복수 단어를 사용할 것을 권장함.

 

HTTP 메서드 

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

 

기타 메서드

• HEAD: GET과 동일하지만 메세지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 메서드를 설명(주로 CORS에서 사용)

 

GET 메서드

• 리소스 조회에 사용
• 메세지 바디는 지원하는 곳이 많지 않기 때문에 권장하지 않으며, 서버에 전달하고 싶은 데이터는 쿼리를 통해서 전달하여야 함

 

POST 메서드

• 요청 데이터를 처리할 때 사용 (예, 전달된 데이터로 신규 리소스를 등록하거나 프로세스 처리에 사용)
• 메세지 바디를 통해 서버로 요청 데이터를 전달함.
• 메서드가 애매하면 대부분 POST를 사용(예전에는 GET과 POST 메서드밖에 없었다고 함)

 

PUT 메서드

• 리소스를 대체하는 메서드(리소스가 있으면 대체, 없으면 생성). 덮어쓰기와 유사한 효과
• 클라이언트가 리소스를 식별할 수 있음. (예, PUT /members/100)
• 리소스를 완전히 대체하는 것을 유의하여야 함

 

PATCH 메서드

• 리소스의 일부를 변경할 때 사용

 

DELETE 메서드

• 리소스를 제거할 때 사용

 

HTTP 메서드의 속성

 

안전(Safe)

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

 

멱등(Idempotent)

• f(f(x)) = f(x)
• 한번 호출하든 여러번 호출하든 결과는 동일하여야 한다.
• GET: 한 번 조회하든, 두번 조회하든 같은 결과가 조회된다.
• PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 수행해도 최종 결과는 같다.
• DELETE: 결과를 삭제한다. 따라서 같은 요청을 여러번 수행해도 삭제 결과는 같다.
• POST: 멱등이 아니다. 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
• 서버가 TIMEOUT 등으로 정상 응답을 주지 못하였을 때, 클라이언트가 같은 요청을 다시 해도 되는가 등에 대한 판단 근거로 활용할 수 있음.

 

캐시 가능(Cacheable)

• 응답 결과를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 결과를 캐시할 수 있으나, 일반적으로 GET, HEAD만 캐시로 사용

 

참고하면 좋은 URI 설계 개념

문서

• 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스의 row), 예를 들어 /members/100, /files/star.jpg

 

컬렉션

• 서버가 관리하는 리소스의 디렉토리
• 서버가 리소스의 URI를 생성하고 관리. 예를 들어, /members

 

스토어

• 클라이언트가 관리하는 자원 저장소
• 클라이언트가 리소스의 URI를 알고 관리

 

컨트롤러(controller), 컨트롤 URI

• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
• 동사를 직접 사용
• 예) /members/{id}/delete