-
GET, POST, PUT, PATCH, DELETE
GET
- 리소스 조회 목적으로 사용
- 해당 자원 리소스를 URL에 검색해서 불러옴
- 서버로 데이터를 전달할 때는 "URL의 query 부분에 작성"해서 보냄
GET /search?q=hello HTTP/1.1
HOST: www.naver.com
POST
- 요청 데이터 처리
- message Body를 이용해서 데이터 전달
- POST 리소스 자원 위치(URL)을 서버가 관리하므로 POST로 들어오는 리소스마다 지정해줘야함
- POST 요청이 올때에 사용 목적에 따라 달라지기에, 해당 리소스 요청이 올때 어떻게 처리할 것인지 리소스 마다 정해야함
POST /main HTTP/1,1
Content-Type = application/json
{
"name" : "pp",
"count" : 1
}
- POST 사용 시기
- 아직 식별되지 않은 새 리소스를 생성
- HTML양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
- 게시판, 블로그 .. 메시지 게시
- ex) 블로그 글쓰기, 게시판 글쓰기, 댓글달기
- 기존 자원에 데이터 추가
- 기존 자원 수정
PUT
- 리소스 대체
- 클라이언트가 리소스 위치 (/main/100) 를 알고 있음 (POST (/main) 와 차이점)
PUT /main/100 HTTP/1.1
Content-Type : application/json
{
"user" : "pp"
"count" : 5
}
- (중요!) PUT 사용시, 수정되지 않는 부분이더라도 다시 보내줘야함
- "user":"pp" 데이터가 바뀌지 않아서, 안보낼경우 "user"필드자체가 없어짐
PUT /main/100 HTTP/1.1
Content-Type : application/json
{
"count" : 5
}
PATCH
- 리소스 부분 변경 가능 (PUT 보완)
- PUT과 마찬가지로 리소스 위치를 알고 있음 (/main/100)
PATCH /main/100 HTTP/1.1
Content-Type : application/json
{
"count" : 10
}
/*
[Server 데이터 저장 정보]
{"user ": "pp" , "count ": 5} -> {"user ": "pp" , "count ": 10 }
*/
DELETE
DELETE /main/100 HTTP/1.1
HOST : www.naver.com
멱등 method (idempotent)
- 멱등 : 여러번 호출해도 변경되지 않고 괜찮은가
- method : GET / PUT /DELETE
- 중요!) POST의 경우 여러번 호출하면 중복해서 발생할 수도 있음 (멱등이 아님)
캐시가능 method
- GET / HEAD / POST / PATCH 캐시 가능
- 실제로는 GET, HEAD 정도만 캐시로 이용
- POST, PATCH 는 구현이 어려움