API URI

API URI 를 설계하기 위해서 가장 중요한것은 자원 그 자체에 초점을 둬야합니다.

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

여기서 리소스는 회원 입니다. 행위는 포함하지 않습니다.

게임에서 미네랄을 캐라 는 미네랄 만 리소스인것 처럼

API URI를 설계를 할때도 회원 그 자체가 리소스 여야합니다.

동사는 HTTP 메서드에서 담당하죠

HTTP 메서드

메소드는 다음과 같습니다.

주요 메서드

• GET: 리소스 조회
  • 서버에 전달하고 싶은데이터는 query 통해서 전달
  • 메세지 바디를 통해서도 가능하지만 권장하진 않음

• POST: 요청 데이터 처리, 주로 등록에 사용
  • 메시지 바디를 통해 서버로 요청 데이터 전달 (클라이언트와 서버가 약속후 서버가 처리)
  • 단순히 값 하나를 변경할때만 사용하지않고 서버에 큰변화를 줄때도 post 를 사용
  • 다른 메서드로 처리하기 애매한것은 모드 POST 로 처리
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
  • 리소스를 덮음,리소스의 위치를 정확히 식별
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제

기타 메서드

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

거의 사용 안함

• CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

HTTP 메서드의 속성

HTTP 메서드의 속성에는 다음과 같은 특징이 있습니다.

• 안전(Safe Methods)
• 멱등(Idempotent Methods)
• 캐시가능(Cacheable Methods)

안전

호출해도 리소스에 변경이 안될경우 예) GET 리소스 조회

멱등

1번호출하든 100 번 호출하든 결과가 같을때
예) GET ,PUT ,DELTE
POST 두번 호출하면 2번결제가 된다. 즉 멱등성이 없다.

멱등은 재반복이 가능한지를 판단하는 기준이 됩니다.

캐시가능

이론상 GET HEAD POST PATCH 는 캐시가 가능하지만
POST 와 PATCH는 구현이 힘들기 때문에 GET과 HEAD 만 사용합니다.