비전공자의 전공자 따라잡기 - 네트워크, HTTP

HTTP 메서드와 REST API

HTTP 메서드

put과 patch 차이

유저 데이터를 수정할 때 전체 데이터를 수정하는 것이면 put을 쓴다.
부분 데이터를 수정할 때는 pacth를 쓴다. 보통은 patch를 더 많이 쓰게 된다.

요청을 보낼 때 단어의 뜻에 맞춰서 보내는 것이 좋다.
꼭 따를 필요는 없지만 의미를 바로 알 수 있는 것이 좋고 명확하다.

HTTP API란?

브라우저에서 어떤 메서드로 어떤 요청을 서버로 보내면 서버에서는 요청한 동작을 이렇게 해주겠다라고 프론트 개발자와 백엔드 개발자가 서로 약속을 하는 것이 ‘HTTP API’다.

서로 콘텐츠 협상을 한다. 헤더도 정하고 캐시, 쿠키나 인증을 어떻게 할지 주소 만들기로 정하고 약속을 한다.

다른 메서드 설명

HEAD : 응답 헤더는 있지만 응답에 바디가 없기때문에 get보다는 비용이 덜 들고, 제대로 라우터가 동작이 잘 되는지 확인용으로 쓴다.

options : 내 서버가 다른 서버에서 요청보내는 것과 응답하는 것을 허용하려고 쓴다.

trace : 어떤 프록시를 썼는지 추적하는 것이다. (프록시 서버 추적)
중간서버라는 것이 있다. 방화벽이나 게이트웨이, 프록시같은 것이다.
중간 서버를 거치면서 헤더가 변조됐을까봐 추적하는 것이다. 우리가 직접쓸 일은 거의 없다.
자세한 건 프록시 강의에서 설명

REST API란?

REST API는 주소를 최대한 더 보기 좋게 만드는 것이다.

모두가 따른다고 말하지만 모두가 따르고 있지 않다고 해서 유니콘같은 존재라고 한다.
정해진 규칙이 없기 때문에 지킬 것이 없다.

안전한 메서드, 멱등성 메서드

get과 post의 보안

get과 post 중에 post가 보안이 더 뛰어난다는 말은 틀린 말이다.
보안은 HTTP와 HTTPS의 차이다. HTTPS가 보안이 더 뛰어나다.
HTTP요청이면 와이어샤크에서 정보가 노출이 되고 HTTPS라면 노출이 되지 않아 보안이 좋다.
html 태그 중에 get인지 post인지 구분하는 태그가 있다.
그런 경우가 아니라면, 요즘은 HTTPS가 필수적이기때문에 별로 차이가 없다.

안전한 메서드

서버의 상태를 바꾸지 않는 메서드가 안전한 메서드다.
대표적으로는 get, optins, trace…

멱등성 메서드

안전한 메서드가 아니면 멱등성이냐?는 틀렸다. 완전히 다른 개념이다.
get, HEAD, options, trace를 포함해서 멱등성이다.
같은 것을 여러번 호출해도 한번만 호출한것과 같다.
최종적으로 서버에서는 아무 영향이 없다. 그렇기때문에 멱등성이다.

안전한 메서드와 멱등성 메서드를 구분하는 이유?

약속만하면 뭐든 됐지만, 안전한 메서드인지 멱등성 메서드인지에 따라 브라우저의 동작이 달라지기때문에 구분을 하는 게 좋다.

put과 delete가 멱등성인 이유?

delete 예시 : 1번 유저를 제거했다. 제거하는 요청을 1번하나 100번하나 서버에서는 똑같다.
put 예시 : 전체를 바꿔버리는데 A를 B로 바꿨다면 또 그렇게 바꾼다해도 서버에서는 달라질 것이 없다.

post와 patch가 멱등성이 아닌 이유?

post 예시 : 유저를 1명 추가하고 또 추가하여 100번 추가하면 유저가 100명 생기는 것이다.

patch 예시 : 조회수를 1씩 올리는 것은 부분만 바뀌는 것인데 그런 경우 100번 요청을 했다면 조회수가 100이 된다.

get이 왜 안전할까?

서버로 부터 데이터를 조회만 하고 서버의 데이터를 변경하지 않아 안전하다.

나머지는 왜 안전하지 않을까?

post를 하면 서버의 게시글들이 생기고 회원이 생기는 경우는 안전하지 않다고 한다.
브라우저는 멱등성이 없는 메서드인 경우 다시 시도하지 않는다.

캐싱

get, HEAD, post

브라우저가 임시적으로 저장을 할 수 가 있다.
어떤 메서드의 결과값을 캐싱할지 말지를 판단하는 기준이 있다.
안전한 메서드 get, HEAD는 응답값을 캐싱을 할 수가 있다.

post도 가능은 하겠지만, 실제로 브라우저는 post를 캐싱안하는 경우가 많다.
put과 patch는 전체 수정과 부분 수정으로도 차이가 있지만 멱등성이냐와 아니냐로 구별하면 된다.

상태 코드(1XX, 2XX)

상태코드

네트워크 탭을 보면 status가 있다.
그 부분을 상태코드라고 하는데 데이터 전송을 실패했는지 성공했는지를 보여준다.

상태코드가 없는 것들은 요청이 실패한 것이다.
요청을 실패했거나 응답이 오지 않은 것이다. (완전한 네트워크 문제)
또는 요청이가고 응답이 왔지만 서버응답쪽에서 실패라고 응답을 해주는 경우도 있다. (네트워크 문제거나 방화벽 등의 문제)

100 200 300 400 500 상태코드 의미

400~500번대는 에러다.

400번대 : 요청은 제대로 갔지만 서버가 요청을 읽으려고 하는데 데이터를 이상한 것을 보내준 경우다.
만약, 어떤 로그인을 하려고 ID와 비밀번호를 보냈는데 서버에서는 그런 데이터를 가지고 있지 않다.
그렇다면 클라이언트에서 정보를 잘못 입력한 것이다. 그렇게 되면 400번대의 에러가 나게 된다.
서버에서 에러나는 경우는 500번대다.

100 200 300은 각각 정보를 말한다.

200번(성공) : 데이터 전송을 하고 제대로 된 응답을 받았다는 의미다.

101번 : HTTP에서 웹소캣으로 전환을 하는 것. 이 때, 서버가 101번으로 응답을 해준다.
그러면 앞으로 브라우저는 웹소캣요청을 보낸다. (101번은 웹소캣할 때 배울 예정)

상태코드는 모두 다른 의미지만 첫번째자리는 비슷한 의미로 약속을 해둔 것이다.
상태코드만 봐도 뭘 해야될지 추측을 하기 쉽다.
혹시나 중간에 비어있는 번호는 회사나 상황에 맞게 자유롭게 잘 사용하면 된다!