API 설계시 가장 중요한것은 ✨리소스 식별✨
행위를 모두 배제
-> 리소스를 URI에 매핑
예시 ) 회원 목록 조회 /members,
회원 조회 /members/{id},
회원 등록 /members/{id} ...
=> 리소스 : 회원 (members)
행위는 어떻게 구분 ? => HTTP 메서드가 이 역할을 대신
👉 리소스 : 명사 / 행위 : 동사
리소스 ( 최근엔 Representation )
HTTP 메서드 : 클라이언트가 서버에 요청을 할 때 기대하는 행동
⬇️ 클라이언트 요청 메세지 예시
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com
⬇️ 서버 응답 메세지 예시
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 34
{
"username": "young",
"age": 20
}
요청 데이터 처리
❗의미가 많음❗
대상 리소스가 리소스 고유 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청
리소스 URI에 POST 요청이 오면
요청 데이터를 어떻게 처리해야할 지 리소스마다 따로 정해야함
⬇️ 클라이언트 요청 메세지 예시
POST /members HTTP/1.1
Content-Type: application/json
{
"username": "young",
"age": 20
}
⬇️ 서버 응답 메세지 예시
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100 < 자원 생성 경로 전송
{
"username": "young",
"age": 20
}
/members로 POST 요청이 오면 신규로 등록할게
신규 리소스 생성 : 201
+ 자원 생성된 경로
보내줌POST 사용하는 경우
⬇️ 클라이언트 요청 메세지 예시
PUT /members/100 HTTP/1.1
Content-Type: application/json
{
"username": "hello",
"age": 20
}
/members/100
으로 클라이언트가 리소스의 위치를 아는 경우 PUT을 사용
⬇️ 클라이언트 요청 메세지 예시
PATCH /members/100 HTTP/1.1
Content-Type: application/json
{
"age": 50
}
⬇️ 클라이언트 요청 메세지 예시
DELETE /members/100 HTTP/1.1
Host: localhost:8080
📌 안전 (Safe)
📌 멱등 (Idempotent)
어디에 활용?
자동 복구 메커니즘
서버가 정상응답을 돌려주지 못할 때, 클라이언트가 같은 요청을 해도 되는가?
재요청 중간 다른곳에서 리소스를 변경시? ( 고려사항 아님! : 외부 요인으로 변경되는것 까지 고려 X )
📌 ✨캐시 가능✨