HTTP API를 만들어보자
좋은 URI 설계를 하려면 가장 중요한 것은 리소스 식별
- URI는 리소스만 식별, URI 계층 구조를 활용
- 리소스와 해당 리소스를 대상으로 하는 행위을 분리
- 리소스 : 회원
- 행위 : 조회, 등록, 삭제, 변경
- 리소스는 명사, 행위는 동사
- 행위는 HTTP 메서드를 사용해서 구분
- 어쩔 수 없이 리소스만으로 되지 않을 때 동사의 URI가 나올 수 있음 > 컨트롤 URI
HTTP 메서드
클라이언트가 서버에 요청을 할때 기대하는 행동
- GET : 리소스 조회
- POST : 요청 데이터 처리, 주로 등록에 사용
- PUT : 리소스를 대체, 해당 리소스가 없으면 생성
- PATCH : 리소스 부분 변경
- DELETE : 리소스 삭제
GET
- 리소스 조회
- 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
- 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
- 클라이언트가 요청 메시지 전달
- 서버 도착, 서버가 내부의 DB 조회 후 응답 메시지를 생성
- 서버가 응답 데이터 전달
POST
- 클라이언트는 메시지 바디를 통해 서버로 요청 데이터 전달
- 서버는 요청 데이터를 처리
- 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
- 클라이언트가 요청 메시지 전달
- 서버는 신규 리소스 생성 (새로운 데이터를 등록한다고 가정했을 때)
- 서버가 응답 데이터 전달
- 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함 > 정해진 것이 없음
- 새 리소스 생성(등록) : 서버가 아직 식별하지 않은 새 리소스 생성
- 요청 데이터 처리 : 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
- 다른 메서드로 처리하기 애매한 경우 : 애매하면 POST
- POST는 사실 메세지를 내부에 담아서 보내는 모든 걸 할 수 있지만 조회할때는 GET을 사용하는것이 유리
PUT
- 리소스가 있으면 완전히 대체(덮어쓰기), 없으면 신규 생성
- 클라이언트가 리소스를 식별, 클라이언트가 리소스 위치를 알고 URI 지정
PUT /members/100> POST와의 차이점POST /members
PATCH
- 리소스 부분 변경
- PATCH가 지원이 되지 않을때는 POST를 사용
DELETE
- 리소스 제거
HTTP 메서드의 속성
안전(Safe Methods)
- 호출해도 리소스를 변경하지 X
- GET, HEAD 등
- 안전은 해당 리소스만 고려
멱등(Idempotent Methods)
- f(f(x)) = f(x) > 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 같음
- GET, PUT, DELETE 등..
- POST는 멱등이 아님(중복 발생 가능성)
- 자동 복구 메커니즘에 활용
- 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 X
캐시가능(Cacheable Methods)
- 응답 결과 리소스를 캐시해서 사용해도 되는가?
- GET, HEAD, POST, PATCH 캐시가능 > 실제로는 GET, HEAD 정도만 캐시로 사용
