강의 모든 개발자를 위한 HTTP 웹 기본 지식을 듣고 정리한 내용입니다.
HTTP 메서드
회원 정보 관리 API를 만들어보자.
이때, 좋은 URI를 설계하기 위해서는 리소스 식별이 중요하다.
리소스란?
회원을 등록하고 수정하고 조회하고 이런 것이 리소스가 아니다.
회원이라는 개념이 리소스이다.
따라서 리소스인 회원만 식별하면 된다. ( = 회원 리소스를 URI에 매핑)
이때, 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장
- 회원 목록 조회 /members
- 회원 조회 /members/{id}
- 회원 등록 /members/{id}
- 회원 수정 /members/{id}
- 회원 삭제 /members/{id}
→ 어떻게 구분할까??
리소스와 행위를 분리하자
URI는 리소스를 판별해야지 리소스의 행위를 판별하는데 사용하면 안된다!!!
- 리소스 : 회원 → 명사
- 행위 : 조회, 등록, 수정, 삭제 → 동사
이때, HTTP 메서드로 이 행위를 구별한다.
GET
- 리소스 조회
- 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
1. 메시지 전달
2. 서버도착
3. 응답 데이터
POST
- 요청 데이터 처리, 주로 등록에 사용
- 서버는 메시지 바디를 통해 전달된 요청 데이터를 처리.
이때, 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다. - 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
1. 메시지 전달
2. 신규 리소스 생성
3. 응답 데이터
PUT
- 리소스를 완전히 대체(덮어씌운다), 해당 리소스가 없으면 생성
- 클라이언트가 리소스를 식별
클라이언트가 리소스 위치를 알고 URI 지정
→ POST와의 차이점!
PATCH
- 리소스 부분 변경
DELETE
- 리소스 삭제
HTTP 메서드 속성
안전 (Safe)
호출해도 리소스를 변경하지 않는다.
ex) GET ..
안전의 경우, 해당 리소스만 고려하기 때문에 계속 호출해서 로그가 쌓여 서버 장애가 발생하는 상황을 고려하지 않는다.
멱등 (Idempotent)
f(f(x)) = f(x)
한번 호출하든 두번 호출하든 100번 호출하든 결과가 똑같다.
ex) GET, PUT, DELETE ..
POST의 경우, 멱등이 아니다. 두번 호출하면 같은 결제가 중복해서 발생할 수 있다.
멱등의 속성을 활용하는 경우, ex. 자동 복구 매커니즘
→ 서버가 TIMEOUT 등 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는 판단 가능하다.
멱등의 경우, 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.
캐시기능 (Cacheable)
응답 결과 리소스를 캐시해서 사용해도 되는지
ex) GET, HEAD, POST, PATCH ..
실제로는 GET, HEAD 정도만 캐시로 사용한다. 왜냐하면 POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않기 때문이다.
