HTTP API를 만들어 보자

API URL 고민

리소스 의미는 뭘까?

• 회원을 등록 수정 조회하는건 리소스가 아님!
  ex) 미네라를 캐라 -> 미네랄이 리소스
• 회원이라는 개념 자체가 바로 리소스
• 리소스를 어떻게 식별하는게 좋을까
  -> 회원을 등록 수정 조회 하는것을 모두 배제
  -> 회원이라는 리소스만 식별하면됨 -> 회원 리소스를 URI 매핑

API URL 설계

회원 목록 조회 / 회원 조회/ 회원 등록 등..

리소스 식별 , URI 계층 구조 활용

그러나 구분을 어케하지?

리소스와 행위를 분리

• URI는 리소스만 식별!

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

리소스 : 회원
행위 : 조회 , 등록 , 삭제 , 변경

리소스는 명사 행위는 동사(미네라를 캐라)

행위(메서드)는 어떻게 구분?

HTTP 메서드 GET/POST

POST : 데이터 보낼테니 처리해줘!
PUT: 파일을 폴더에넣는개념 (새로만들거나/변경)
PATCH: 부분변경 회원이름 바꿀때

최근스펙에는 리소스 -> Representation

CONNECT , TRACE는 거의 사용하지 않는다.

path에 있는 자원을 주세요!

그림으로 설명 최초 /members/100 HTTP/1.1 요청!

POST

서버에서 데이터 베이스에 등록후
신규 리소스 식별자 생성 /members/100

자원이 생성된 경로도 보내줌

POST 의미

HTTP - PUT , PATCH ,DELETE

-> 폴더에 파일을 복사하는 거랑 비슷함.
(완전히 대체한다는게 중요함)

클라이언트가 리소스 정확한 위치를 알고. URI 지정
(POST 랑 차이점 /members <-> /members/100)
(디렉토리 개념으로보면 전체폴더 위치냐 상세한 폴더위치?차이) 개인적인 생각

주의 점 완전히 대체 되버림..

-> 리소스를 수정하는게아니라 완전히 대체해버린다.

PATCH

리소스를 부분적으로만 변경한다.

HTTP 매서드 속성

안전

ex) get은 단순 조회라 안전함
나머지는 불안전(변경이 일어나기 때문에)

멱등

몇번을 호출 하든 결과는 똑같아야 된다.

ex) delete 를 호출했는데 응답이 없다?
다시 delete 재시동

이런 경우 까지 고려하지 않음

캐시가능 (Cacheable)

웹 브라우저에 이미지 큰걸 요청
또 요청? 로컬 PC에 웹브라우저 캐시 저장.

-> 캐시를 하려면 똑같은 리소스랑 키가 맞아야됨.
POST , PATCH는 구현하기 쉽지않아 패스함