API URI 설계

 

URI는 리소스만 식별한다.

 

Resource를 기준으로 설계해야 함!

 

- 회원 목록 조회 /members

- 회원 조회 /members/{id}

- 회원 등록 /members/{id}

- 회원 수정 /members/{id}

- 회원 삭제 /members/{id}

 

리소스와 행위를 분리해야 한다.

가장 중요한 것은 리소스를 식별하는 것

URI는 리소스만 식별하게 됨

리서스와 해당 리소스를 대상으로 하는 행위를 분리

 

여기서 리소스를 대상으로 하는 행위를 HTTP메서드라고 한다.

 

---

HTTP 메서드 

 

-GET: 리소스 조회

  서버에 전달하고 싶은 데이터는 쿼리 스트링을 통해서 전달

  메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지는 않음

 

-POST: 요청 데이터 처리, 주로 등록에 사용

   요청 데이터를 처리하는 역할

   메시지 바디를 통해 서버로 요청 데이터 전달

   서버는 요청 데이터를 처리

   주로 전달된 데이터로 신규 리소스를 등록하고 프로세스 처리에 사용한다.

   정리하자면

    1. 새 리소스 생성할때

    2. 요청 데이터를 처리해야할 때

    3. 다른 메서드로 처리하기 애매한 경우

    에 사용한다.

 

-PUT: 리소스를 대체, 해당 리소스가 없으면 생성

    기존 리소스를 완전히 대체한다. (아예 갈아치운다고 생각하면 편함. 부분만 덮어씌우는게 아니라 완전히        새 것처럼 덮어씌움)

    리소스가 없으면 생성

    쉽게 이야기해서 덮어쓰는 메서드!

    클라이언트가 리소스 위치를 알고 URI를 지정한다는 점이 POST와 차이점이다.

    

 

-PATCH: 리소스 부분 변경

   리소스를 부분적으로 변경하고 싶을때 씀

    

-DELETE: 리소스 삭제

 

---

HTTP 메서드의 속성

 

1. 안전

 

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

 

2. 멱등

 

f(f(x)) = f(x)

한번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.

get - 계속 호출하든 같은 결과가 조회됨

put - 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같음

delete - 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 같다.

post -  멱등이 아님! 두번 호출하면 같은 결제가 중복해서 발생할 수 있다!

 

자동 복구 매커니즘에 사용할 수 있다.

멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않음

같은 데이터를 기준으로 생각하면 편함.

 

3. 캐시가능

 

 응답 결과 리소스를 캐시해서 사용해도 되는가?

 get,head,post,patch 캐시 가능하지만 실제로는 get,head정도만 캐시로 사용 

 

---

출처- 모든 개발자를 위한 HTTP웹 기본 지식 

www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard