해야할 일은 요구사항 확인이다.
만들고자 하는 서비스에 어떤 기능이 있어야하는지를 생각하고 정리한다.
우선 이번 서비스의 요구사항은 아래와 같다고 예를 든다.
- 회원 목록 조회
- 회원 조회
- 회원 등록
- 회원 수정
- 회원 삭재
인터넷에서 어떻게 식별할 것인지를 정한다.
이 말은 아래와 같은 패치를 정하는 것과도 같다.
http/들어가고 port번호 등은 이미 정해져있기 때문에 우리는 뒤에 패치를 사용해서 인터넷 주소를
만들어야 한다.
path
: 리소스 경로, 계층적 구조
/home/file.jpg
/members
/members/10
- 회원 목록 조회 /read-member-list
- 회원 조회 /read-member-by-id
- 회원 등록 /create-member
- 회원 수정 / update-member
- 회원 삭제 /delete-member
=> 좋은 URI 인가 고민해보자.
URI(Uniform Resource Identifier)
리소스를 식별하는 통합된 방법이다.
그렇다면 우리가 하려는 서비스에서의 리소스는?
회원이다.
리소스는 어떻게 식별하면 좋을까?
회원을 등록, 수정,조회는 일단 배제하고
-회원이라는 리소스만 식별해라. -> 회원만 URI에 먼저 맵핑
- 회원 목록 조회 /members
- 회원 조회 /members{id}
- 회원 등록 /members{id}
- 회원 수정 /members{id}
- 회원 삭제 /members{id}
=> 조회 등록 수정, 삭제는 구분할 수 없는 오류가 생긴다.
그래서 uri어떻게 설계하라는건지??
바로
가장 중요한 것은 리소스를 식별하는 것이기 때문에
그럼 행위는 어떻게 표현할 건지 알아보자.
GET : 리소스를 조회
POST : 요청 데이터를 처리, 주로 등록
PUT : 리소스를 보내는데,그 리소스가 있으면 대체하고, 없으면 생성한다.
파일을 -> 폴더에 넣음, 기존에 폴더안에 같은 파일이 있으면 대체하고,
없으면 그냥 들어가서 생성되는 것과 같음
PATCH : 리소스를 부분 변경 (회원 이름을 변경)
DELETE : 리소스를 삭제
HEAD : get이랑 동일한데, 메세지 부분만 제외하고 상태랑 헤더만 반환한다.
OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 설명 (cors에서 사용)
get/members/100 HTTP/1.1
host: www.google.com
만약에 이렇게 왔다면,
서버가 get을 보자마자 아 뭘 달라고 하는구나, members에 100번을 . 이라고 이해해서
디비에서 값을 꺼내서 응답 메세지에 넣어서 보내준다.
POST/members/100 HTTP/1.1
Content-Type:application/json
{
"username":"hello"
"age" : 20
}
서버가 post 를 보면 아 요청하는 거구나 알고, 내용을 보니 유저네임과 나이를 클라이언트가
줬으니 서버가 받아서 처리해줘. 라고 하는 것이다.
주로 등록을 하거나 수정을 하는데 쓰인다.
클라이언트가 members에 post method로 보내면 그 데이터는 내가 데이터 베이스에
저장할거야 ~ 와 같은 약속을 한다. 그리고 신규로 등록을 한다.
등록을 하면 식별자를 생성한다.
이런 서로의 약속을 한다.
신규로 자원이 생성되는 http code 가 201으로 보낸다.
Location 은 신규로 생성된 자원의 경로를 보내준다.
그런데 post 는 등록 외에도 수정을 한다던가, 자원을 추가한다던가 다른 기능들을 수행할 수 있기 때문에
리소스 마다 어떻게 처리할 것인지 정해야한다.
역할을 정리하자면
json으로 조회 데이터를 넘겨야 하는데, get 메소드로 사용이 어려운 경우
애매하면 post로 보낸다.
동사 URI 를 컨트롤 URI라고 한다.