API URI 설계
리소스와. 해당 리소스를 대상으로 하는 행위를 분리
예를 들어,
멤버 등록
멤버 수정
멤버 조회
여기서 리소스는, 멤버이고, 그 뒤의 내용이 행위이다.
행위는 우리가 아는 http 메서드(get, post, put..)이다.
그래서! URI는 리소스만 식별하면 된다.
왜?
어차피 해당 리소스로 어떤 행위를 할지는, HTTP매소드가 결정할 내용이니깐.
if 리소스만으로 작성할 수 없다면,
/orders/{orderId}/start-delivery 이런식으로 만들기도하고,
컨트롤 uri라고 한다.
and
다른 매서드로 처리하기 애매하면 post를 사용한다.
HTTP 메서드의 종류
- GET : 리소스 조회
- POST : 요청 데이터 처리 (주로 데이터 등록)
- PUT : 리소스 대체 (파일 덮어쓰기)
- PATCH : 리소스 부분 수정
- DELETE : 리소스 삭제
GET 매서드 예시
/members/100 == 100번 멤버의 정보를 주세요 가 위의 이미지
그에 해당하는 정보를 response로 보내주는게 아래 이미지
{
"username": "young",
"age": 20
}
POST 매서드 예시
주로 리소스 등록에 이용.
아래 내용을 /members 로 보내서 등록할게요! 가 위의 이미지
{
"username": "young",
"age": 20
}그에 해당하는 내용을 등록하는게 아래의 이미지
보통 게시판 글쓰기, 댓글달기, 주문생성 등의 기능에 생성됨.
말그대로 post 게시기능.
각각의 리소스 uri에 post요청이 오면 각각 요청온 데이터를 어떻게 처리할지 정해야함
(게시글을 어떤 정보(제목, 내용, 이미지 등등)를 받아서 어떻게 등록할것인지, 주문은 어떤 정보(주문자, 금액, 주문요청, 시간 등등)를 받아서 어떻게 생성할것인지)
PUT 매서드 예시
- 리소스가 없으면 생성, 있으면 대체
- 덮어쓰기 느낌.
- 덮어쓰기 느낌이므로, 내가 원하는 필드만 수정하기 위해선 나머지 필드는 이전과 같은 데이터를 넣어야함. (상태성 느낌...?)
POST와의 차이점은, 리소스를 식별해서 넣을 수 있음
어.. 무슨말이냐?
1. post 는 /members (멤버 번호 몰라도 된다)
2. put 은 /members/10 (10번의 멤버에게 put 요청을보내겠다! 라는 뜻)
원래 아래와 같은 정보를 가진 10번의 member가 있다고 하자.
{
"username": "young",
"age": 20
}내가 해당 멤버에 아래와 같은 put요청을 보내면,
{
"age": 50
}결과는 아래와 같다.
{
"age": 50
}PATCH 매서드 예시
patch 매서드에선, put 매서드와 다르게 원하는 필드만 수정 가능!
예시
원래 아래와 같은 정보를 가진 10번의 member가 있다고 하자.
{
"username": "young",
"age": 20
}내가 해당 멤버에 아래와 같은 put요청을 보내면,
{
"age": 50
}결과는 아래와 같다.
{
"username": "young",
"age": 50
}DELETE 매서드 예시
리소스를 삭제!
/members/100 -> 100번 member 삭제할게요!
HTTP 메서드의 속성
-
안전
호출해도 리소스를 변경하지 않음. (get 계속해도 리소스는 그대로다)
여기서 질문.
Q. 겟요청 엄청많이하면 서버에 무리가서 장애발생해서 데이터 소실되면요?
A. 서버장애 != 리소스변경 -
멱등
f(x) = f(f(x)), post만 빼고.
예를 들어, put을 계속 날리면 계속 같은 내용으로 리소스가 덮어씌워진다.
여기서 질문.
Q. 멱등은 알겠는데, 이 속성이 왜 필요하냐?
A. 서버가 응답 못했을때, 클라이언트가 같은 내용으로 다시 요청 가능. (자동 복구 메커니즘)
또 질문.
Q. 그럼 get, patch, get과 같은 순서대로 재요청할때 리소스가 변경되면, 응답으로 같은 내용이 안오지 않느냐?
A. f(g(f(x))) != f(x)이다.
- 캐시 가능
캐시 메모리에 등록해놓고 빨리빨리 꺼내 쓸 수 있게 하는것
GET, HEAD, POST, PATCH 캐시가능이지만,
실제로는 GET 정도만 캐시로 사용한다.
