URI 설계에서 가장 중요한 것은 리소스 식별이다. 회원 정보를 관리하는 API를 만든다고 가정했을 때 설계 리소스의 의미는 회원을 등록하고 수정하고 조회하는 게 리소스가 아니다. 회원이라는 개념 자체가 바로 리소스다. 회원을 등록하고 수정하고 조회하는 것을 모두 배제하고 회원이라는 리소스만 식별하면 된다. 즉 회원 리소스를 URI에 매핑하면 된다. 그리고 리소스와 해당 리소스를 대상으로 하는 행위를 분리해야 한다. 리소스는 회원이면 행위에 해당하는 것은 조회, 등록, 삭제, 변경에 해당한다. HTTP 메서드가 행위를 대신할 수 있다.
단어 그대로 리소스를 조회하는 역활이다. 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달하고 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.
주로 새 리소스를 생성하고 등록하는데 사용된다. 그리고 요청 데이터를 처리하는 역활을 한다. 메세지 바디를 통해 서버로 요청 데이터를 전달하면 서버는 요청 데이터 메세지의 바디로 통해 들어온 데이터를 처리하는 모든 기능을 수행한다. 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용된다. 다른 메서드로 처리하기 애매한 경우에 자주 사용된다.
리소스를 대체하는 역할을 한다. 파일 안에 폴더가 있다고 가정해서 폴더 안에 붙여넣기를 한다면 파일은 대체된다. 즉 리소스가 없으면 생성하고 있으면 덮어버린다. 중요한 것은 POST와 차이점은 클라이언트가 리소스 위치를 알고 URI를 지정해야 한다.
리소스를 부분 변경하는 것이고 새로 나온 메서드이다.
리소스를 제거한다.
호출해도 리소스가 변경하지 않는 것을 안전하다고 한다. 안전은 해당 리소스만 고려해서 계속된 호출로 로그가 쌓여서 장애가 발생하는 부분은 고려하지 않는다.
한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같아야 멱등 하다고 한다. GET은 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다. PUT은 결과를 대체한다. 따라서 같은 요청을 여러 번 해도 최종 결과는 같다. DELETE는 결과를 삭제한다. 같은 요청을 여러 번 해도 삭제된 결과는 똑같다. 그러나 POST는 멱등이 아니다. 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.