GET vs POST
GET
정보를 조회하기 위해 설계된 메서드
GET은 정보를 요청할 때 body에 값을 담을 수 없으며 필요하다면 qeuryString을 이용할 수 있다.
POST
리소스를 생성/변경하기 위해 설계된 메서드
POST는 리소스를 변경해야하기 때문에 body에 값을 담아서 전송해야한다(필수)
queryString을 사용하지 않기 때문에 URL에 정보가 담기지 않아 GET보다는 보안적인 측면에서 나으나 보려고하면 얼마든지 볼 수 있기 때문에 민감한 정보라면 암호화해서 보내야한다.
멱등성?
결론부터 말하면 GET은 멱등하며 POST는 멱등하지 않다.
멱등하다는 것은 동일한 연산에 대해서 항상 동일한 결과를 나타내는 것을 말하며 서버로 GET요청을 하면 항상 같은 응답값이 돌아와야한다는 것을 얘기한다.
이러한 특성 때문에 동일한 GET요청은 캐싱될 수 있다.
반대로 POST는 멱등하지 않으며 생성, 삭제, 수정의 생성과 변경이 가능한 메서드이기 때문에 항상 같은 응답값이 돌아온다고 보장되지 않는다.
번외) POST vs PUT vs PATCH
주로 POST는 생성에 PUT과 PATCH는 수정에 사용한다.
POST는 리소스의 생성을 담당하고 있기 때문에 요청시마다 새로운 리소스를 반환한다. 그래서 위에서 멱등하지 않다고 얘기했다.
1
2
3
4
5
POST /student
{
“name”: “뽀로로”,
“grade”: 1
}
PUT과 PATCH는 이미 존재하고 있는 리소스의 변경을 담당하고 있다. 그래서 요청 메세지를 보내는 것에서 차이가 난다.
1
2
3
4
5
PUT /student/3
{
“name”: ”에디”
“grade”: 2
}
POST는 생성이기 때문에 그냥 메세지를 날리면되지만 PUT은 이미 존재하는 리소스의 id값을 같이 넣어서 요청해야한다.
PUT 요청은 반복해서 보내도 같은 리소스에 대한 요청을 반복하기 때문에 같은 반환값이 돌아오게 된다. 따라서 멱등성을 만족한다.
PUT vs PATCH
그렇다면 PUT 과 PATCH는 둘 다 수정인데 무엇이 다를까
PUT은 변경될 데이터 전체를 다 보내주어야한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{ // 요청 전
“name”: ”에디”
“grade”: 1
}
// 요청
PUT /student/3
{
“name”: ”에디1”
}
{ // 요청 후
“name”: ”에디1”,
"grade": null
}
위 처럼 변경하고자 하는 데이터만 담아서 보내버리면 나머지 데이터는 null로 변경되어버린다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{ // 요청 전
“name”: ”에디”
“grade”: 1
}
// 요청
PATCH /student/3
{
“name”: ”에디1”
}
{ // 요청 후
“name”: ”에디1”,
"grade": 1
}
반면에 PATCH는 일부 데이터만 보낼경우 해당되는 데이터만 변경되고 나머지는 기존의 데이터를 가져다 쓴다.
Cache?
그렇다면 캐시는 무엇일까
주어진 리소스의 복사본을 저장하고 있다가 요청이 들어오면 그걸 그대로 돌려주는 기술.
서버에 부담을 줄일 수 있고 클라이언트에는 응답시간을 줄여주는 성능 향상을 보일 수 있다.
하지만 리소스가 불변한 성질이 아니라면 계속해서 리소스가 변했음에도 같은 리소스를 응답하는 문제가 있을 수 있다.
캐시는 두 가지로 분류할 수 있다
사설 브라우저 캐시
브라우저에 달려있는 캐시다. 컨텐츠를 캐싱해서 보여주고 뒤로가기나 앞으로가기 등에 사용된다
공유 프록시 캐시
브라우저에 달려있는 캐시는 개개인의 브라우저에서 캐싱하는 것이지만 공유 프록시 캐시는 다사용자의 요청 자체를 캐싱하는 서버같은 것
캐시 제어
HTTP 헤더에는 캐시 정책을 정의할 수 있는 Cache-control헤더가 존재한다
Cache-Control: no-store
캐시를 허용하지 않는 것. 요청은 서버로 전송되고 전체 응답은 매번 다운로드 된다.
Cache-Control: no-cache
이름만 보면 캐시하지 않는 것 같지만 캐시를 하긴 한다. 대신 사용자에게 전달하기 전에 유효성 확인을 위해 서버로 요청을 보낸다.
근데 이 경우 캐시의 역할을 할 수 있는가? 더 리소스를 잡아먹는 건 아닌지 궁금.
Cache-Control: public or private
public은 프록시서버에 캐시 저장 허용, private는 브라우저단에만 허용
Cache-Control: max-age=«second>second>
리소스가 유효하다고 판단되는 최대 시간을 설정해서 그 시간 만큼 캐싱하는 것
변경되지 않을 파일에 대해 아주 긴 시간을 캐싱하도록 설정할 수 있다. Ex) 이미지, css, js, 정적파일들
유효성
리소서는 캐싱되고나면 사실 영원히 저장되어 요청에 반응할 수 있다. 하지만 유한한 저장공간을 가지고 있기 때문에 주기적으로 스토리지에서 제거되는데 이러한 과정을 캐시 축출이라고 부른다.
만료된 리소스를 실효(stale)상태에 있게되는데 이 실효된 리소스는 바로 축출되거나 무시되지 않고 이 리소스에 대한 요청이 들어올 경우 이 리소스가 유효한지 아닌지를 확인하기 위해서 서버에 요청을 전달하고 서버는 본문을 전송하지 않고 304(Not Modified)를 보내서 대역폭을 절약한다.
Expires나 max-age로 캐시 기간이 설정되어있지 않다면 Last-Modified 헤더를 찾아서 휴리스틱으로 유효 기간을 추정한다
https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/
https://developer.mozilla.org/ko/docs/Web/HTTP/Caching