참고
HTTP API를 만들어보자!(HTTP 메서드 사용이유)
HTTP API - 설계 1 
NOTE
API 기능에 대응하는 직관적인 이름으로 URI를 설계하면, 다음처럼 URI를 모두 따로 만들어야 한다.
1.
회원 목록 조회
•
/read-member-list
2.
회원 조회
•
/read-member-by-id
3.
회원 등록
•
/create-member
4.
회원 수정
•
/update-member
5.
회원 삭제
•
/delete-member
•
이것은 좋은 URI 설계가 아니다! (가장 중요한 것은 리소스 식별)
•
리소스 : 회원
•
등록, 수정, 조회는 리소스가 아님!
HTTP API - 설계 2
NOTE
회원이라는 리소스만 식별해서 만든다! (동작 제외)
1.
회원 목록 조회
•
/members
2.
회원 조회
•
/members/{id}
3.
회원 등록
•
/members/{id}
4.
회원 수정
•
/membersr/{id}
5.
회원 삭제
•
/members/{id}
•
이렇게하면 회원 조회/등록/수정/삭제 URI를 어떻게 구분할수가 없다!
◦
리소스에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다!
◦
회원(명사) 와 조회,등록,수정,삭제(동사)를 분리한다.
Q. members/1 이 아니라 members?id=1 이런식으로 써야하는 거 아닌가?
•
path와 query는 리소스를 식별하기 위해 함께 쓰인다
•
query를 써서 members?id=1과 같이 사용할 수도 있지만 관례적으로 리소스를 식별할 때
id(식별자)는 members/1과 같이 path를 사용한다.
HTTP 메서드 종류
NOTE
메소드 요약
GET
NOTE
리소스 조회에 사용된다!
•
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해 전달
•
메시지 바디를 통해서도 전달이 가능하나, 지원하지 않는 곳이 많아 권장하지 않음
GET 통신과정
1.
메시지 전달
클라이언트가 members/100 유저를 조회하기 위해 GET 방식으로 HTTP 요청 메시지를
서버에 전달한다
2.
서버 도착
서버에 GET메시지가 도착하면, 서버는 GET메시지를 해석하여 DB에서 member/100
유저를 조회해서 JSON 메시지를 만든다
3.
응답 데이터
서버는 조회에 성공했다는 의미로, 반환 메시지를 던져준다.
POST
NOTE
메시지 바디를 통해 서버로 요청 데이터를 전달하는데 사용한다!
•
메시지 바디를 통해 서버로 요청 데이터 전달
POST 과정
1.
메시지 전달
message-body에 데이터를 남아서 POST로 요청 메시지 보냄
2.
서버 도착
POST 메세지를 해석하고 처리한다.
3.
응답 데이터
성공적으로 처리하면, 응답메시지 반환
POST가 사용되는 곳
NOTE
1.
HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
•
HTML FORM에 입력한 정보로 회원가입 진행
2.
게시판, 뉴스, 그룹 또는 유사한 기사 그룹에 메시지 게시
•
게시판 글쓰기, 댓글 달기
3.
서버가 아직 식별하지 않은 새 리소스 생성
•
신규 주문 생성
4.
기존 자원에 데이터 추가
•
한 문서 끝에 내용 추가하기
POST 참고
•
POST는 단순히 데이터 등록으로만 사용되지 않는다
◦
JSON으로 조회 데이터를 넘길때 GET을 사용하기 어려우면 POST의 message-body에 조회 데이터를 넘김
•
기본 리소스만으로 URI를 무조건 생성해야하는건 아님
◦
컨트롤 URI → satart-delivery와 같은 동사를 사용할 수도 있음
PUT
NOTE
리소스가 있으면 대체하고, 없으면 생성하는 용도이다!
•
클라이언트가 리소스 위치를 알고 URI를 지정한다(POST와의 차이점)
◦
POST → /members ( 클라이언트는 리소스 위치 모름)
◦
PUT → /members/100 (클라인터는 리소스 위치 알고 URI를 지정)
PUT 과정
•
리소스가 있는 경우(기존 값 대체)
1.
메시지 전달
2.
리소스 대체
•
리소스가 없는 경우(신규 리소스 생성)
1.
메시지 전달
2.
신규 리소스 생성
PUT 주의점
•
PUT은 리소스를 완전히 대체한다
1.
age의 값만 변경하기 위해 message-body에 username은 빼고 age값만 보낸다
2.
리소스를 덮어쓰기 때문에 message-body에 있는 age 값만 들어가고 username
필드가 삭제된다
PATCH
NOTE
PUT과 달리 기존의 리소스를 유지하고, 부분만 변경한다!
PATCH 과정
1.
메시지 전달 (age의 값만 변경하기 위해 username을 빼고 age만 담아서 보낸다)
•
만약 요청받은 URI가 없다면 에러가 오류가 발생한다.
2.
리소스 부분변경 (message-body에 있는 age만 변경됨)
DELETE
NOTE
리소스 제거에 사용된다!
DELETE 과정
1.
요청 메시지 전달 ( /memebers/100에 있는 리소스를 제거해라 )
2.
리소스 제거
HTTP 메서드 질문
Q. /orders/{orderId}/start-delivery 는 배달 상태 변경의 의미에서 POST가 아닌 PATCH를 사용해야하는 거 아닌가?
•
배달 상태를 변경 → 단순히 해당 리소스의 값을 변경하는 정도로 끝나는게 아니라, 내부에서
매우 큰 프로세스가 실행된다
•
이렇게 해당 리소스만 변경하는 것이 아니라 내부 프로세스를 실행해야할 때는
PATCH 보다 POST를 사용하는 것이 좋다.
(단순히 회원정보를 변경, 특정 리소스의 데이터를 변경할 떄는 PATCH 사용이 좋음)
(참고)
Q. POST와 PUT 모두 리소스가 없으면 생성할 수 있는데, 이 둘의 차이점은 무엇인가?
•
POST
◦
클라이언트가 서버에 요청을 보낼 떄 마다 새로운 리소스를 생성하고, 생성한 리소스
아이디를 반환한다 ( 같은 요청을 반복하면 리소스 아이디가 새롭게 바뀜 )
•
PUT
◦
처음 리소스가 없다면 새로 생성한 리소스 아이디를 반환하고, 이후에 같은 요청을
보내면 처음 생성 했던 리소스의 아이디만 반환한다.
( 같은 요청 반복해도 리소스 아이디가 같다)
HTTP API를 만들어보자!(HTTP 메서드 사용이유)
HTTP API - 설계 1
NOTE
API 기능에 대응하는 직관적인 이름으로 URI를 설계하면, 다음처럼 URI를 모두 따로 만들어야 한다.
1.
회원 목록 조회
•
/read-member-list
2.
회원 조회
•
/read-member-by-id
3.
회원 등록
•
/create-member
4.
회원 수정
•
/update-member
5.
회원 삭제
•
/delete-member
•
이것은 좋은 URI 설계가 아니다! (가장 중요한 것은 리소스 식별)
•
리소스 : 회원
•
등록, 수정, 조회는 리소스가 아님!
HTTP API - 설계 2
NOTE
회원이라는 리소스만 식별해서 만든다! (동작 제외)
1.
회원 목록 조회
•
/members
2.
회원 조회
•
/members/{id}
3.
회원 등록
•
/members/{id}
4.
회원 수정
•
/membersr/{id}
5.
회원 삭제
•
/members/{id}
•
이렇게하면 회원 조회/등록/수정/삭제 URI를 어떻게 구분할수가 없다!
◦
리소스에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다!
◦
회원(명사) 와 조회,등록,수정,삭제(동사)를 분리한다.
Q. members/1 이 아니라 members?id=1 이런식으로 써야하는 거 아닌가?
•
path와 query는 리소스를 식별하기 위해 함께 쓰인다
•
query를 써서 members?id=1과 같이 사용할 수도 있지만 관례적으로 리소스를 식별할 때
id(식별자)는 members/1과 같이 path를 사용한다.
HTTP 메서드 종류
NOTE
메소드 요약
GET
NOTE
리소스 조회에 사용된다!
•
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해 전달
•
메시지 바디를 통해서도 전달이 가능하나, 지원하지 않는 곳이 많아 권장하지 않음
GET 통신과정
1.
메시지 전달
클라이언트가 members/100 유저를 조회하기 위해 GET 방식으로 HTTP 요청 메시지를
서버에 전달한다
2.
서버 도착
서버에 GET메시지가 도착하면, 서버는 GET메시지를 해석하여 DB에서 member/100
유저를 조회해서 JSON 메시지를 만든다
3.
응답 데이터
서버는 조회에 성공했다는 의미로, 반환 메시지를 던져준다.
POST
NOTE
메시지 바디를 통해 서버로 요청 데이터를 전달하는데 사용한다!
•
메시지 바디를 통해 서버로 요청 데이터 전달
POST 과정
1.
메시지 전달
message-body에 데이터를 남아서 POST로 요청 메시지 보냄
2.
서버 도착
POST 메세지를 해석하고 처리한다.
3.
응답 데이터
성공적으로 처리하면, 응답메시지 반환
POST가 사용되는 곳
NOTE
1.
HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
•
HTML FORM에 입력한 정보로 회원가입 진행
2.
게시판, 뉴스, 그룹 또는 유사한 기사 그룹에 메시지 게시
•
게시판 글쓰기, 댓글 달기
3.
서버가 아직 식별하지 않은 새 리소스 생성
•
신규 주문 생성
4.
기존 자원에 데이터 추가
•
한 문서 끝에 내용 추가하기
POST 참고
•
POST는 단순히 데이터 등록으로만 사용되지 않는다
◦
JSON으로 조회 데이터를 넘길때 GET을 사용하기 어려우면 POST의 message-body에 조회 데이터를 넘김
•
기본 리소스만으로 URI를 무조건 생성해야하는건 아님
◦
컨트롤 URI → satart-delivery와 같은 동사를 사용할 수도 있음
PUT
NOTE
리소스가 있으면 대체하고, 없으면 생성하는 용도이다!
•
클라이언트가 리소스 위치를 알고 URI를 지정한다(POST와의 차이점)
◦
POST → /members ( 클라이언트는 리소스 위치 모름)
◦
PUT → /members/100 (클라인터는 리소스 위치 알고 URI를 지정)
PUT 과정
•
리소스가 있는 경우(기존 값 대체)
1.
메시지 전달
2.
리소스 대체
•
리소스가 없는 경우(신규 리소스 생성)
1.
메시지 전달
2.
신규 리소스 생성
PUT 주의점
•
PUT은 리소스를 완전히 대체한다
1.
age의 값만 변경하기 위해 message-body에 username은 빼고 age값만 보낸다
2.
리소스를 덮어쓰기 때문에 message-body에 있는 age 값만 들어가고 username
필드가 삭제된다
PATCH
NOTE
PUT과 달리 기존의 리소스를 유지하고, 부분만 변경한다!
PATCH 과정
1.
메시지 전달 (age의 값만 변경하기 위해 username을 빼고 age만 담아서 보낸다)
•
만약 요청받은 URI가 없다면 에러가 오류가 발생한다.
2.
리소스 부분변경 (message-body에 있는 age만 변경됨)
DELETE
NOTE
리소스 제거에 사용된다!
DELETE 과정
1.
요청 메시지 전달 ( /memebers/100에 있는 리소스를 제거해라 )
2.
리소스 제거
HTTP 메서드 질문
Q. /orders/{orderId}/start-delivery 는 배달 상태 변경의 의미에서 POST가 아닌 PATCH를 사용해야하는 거 아닌가?
•
배달 상태를 변경 → 단순히 해당 리소스의 값을 변경하는 정도로 끝나는게 아니라, 내부에서
매우 큰 프로세스가 실행된다
•
이렇게 해당 리소스만 변경하는 것이 아니라 내부 프로세스를 실행해야할 때는
PATCH 보다 POST를 사용하는 것이 좋다.
(단순히 회원정보를 변경, 특정 리소스의 데이터를 변경할 떄는 PATCH 사용이 좋음)
(참고)
Q. POST와 PUT 모두 리소스가 없으면 생성할 수 있는데, 이 둘의 차이점은 무엇인가?
•
POST
◦
클라이언트가 서버에 요청을 보낼 떄 마다 새로운 리소스를 생성하고, 생성한 리소스
아이디를 반환한다 ( 같은 요청을 반복하면 리소스 아이디가 새롭게 바뀜 )
•
PUT
◦
처음 리소스가 없다면 새로 생성한 리소스 아이디를 반환하고, 이후에 같은 요청을
보내면 처음 생성 했던 리소스의 아이디만 반환한다.
( 같은 요청 반복해도 리소스 아이디가 같다)