HTTP 요청 메소드 POST와 GET의 차이

HTTP 메세지

> HTTP 요청 메세지

> HTTP 응답 메세지

HTTP 메시지에 모든 것을 전송

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

---

시작라인

요청 메시지

start-line = request-line / status-line

request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)

• HTTP 메서드 (GET: 조회)
• 요청 대상 (/search?q=hello&hl=ko)
• HTTP Version

---

💫요청 메시지 - HTTP 메서드

• 종류: GET, POST, PUT, DELETE...
• 서버가 수행해야 할 동작 지정
• GET: 리소스 조회 /  POST: 요청 내역 처리

---

요청 메시지 - 요청 대상

• absolute-path[?query] (절대경로[?쿼리])
• 절대경로= "/" 로 시작하는 경로
• 참고: *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다

---

요청 메시지 - HTTP 버전

• HTTP Version

---

HTTP 헤더

• header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
• field-name은 대소문자 구문 없음

요청의 헤더

 

용도

• HTTP 전송에 필요한 모든 부가정보(ex. 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보... 등 필요한 정보는 거의 있다고 보면 됨)
• 표준 헤더가 너무 많음 • https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
• 필요시 임의의 헤더 추가 가능 (helloworld: hihi)

---

HTTP 메시지 바디

• 실제 전송할 데이터
• HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

---

HTTP 메소드

API URI 설계 시,

리소스 식별, URI 계층 구조 활용 URI는 리소스만 식별 리소스와 해당 리소스를 대상으로 하는 행위을 분리, 리소스는 명사, 행위는 동사 

HTTP 메소드 종류

• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제

• HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
• CONNECT: 대상 리소스로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

---

GET

• 리소스 조회(데이터를 읽거나(Read), 검색(Retrieve)할 때에 사용)
• 오로지 데이터를 읽을 때만 사용되고 수정할 때는 사용하지 않는다.
  • 이런 이유로 사용하면 안전하다고 간주되죠. 즉, 데이터의 변형의 위험없이 사용할 수 있다는 뜻
  • GET 요청은 중요한 정보를 다루면 안된다. (보안)
    • 파라미터에 내용이 노출되기 때문에 민감한 데이터를 다룰 때 GET 요청을 사용해서는 안 된다.

• GET 요청은 길이 제한이 있다.
• GET 요청은 브라우저 히스토리에 남는다.
• GET 요청을 북마크에 추가할 수 있다.
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.
• 서버에 전달하고 싶은 데이터는 URL 주소 끝에 파라미터로 포함되어 전송되고 이 부분을 query(쿼리 파라미터, 쿼리 스트링)이라고 한다.
• GET은 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있다.
  •  js, css, 이미지 같은 정적 컨텐츠는 데이터양이 크고, 변경될 일이 적어서 반복해서 동일한 요청을 보낼 필요가 없다. 정적 컨텐츠를 요청하고 나면 브라우저에서는 요청을 캐시해두고, 동일한 요청이 발생할 때 서버로 요청을 보내지 않고 캐시된 데이터를 사용한다. 그래서 프론트엔드 개발을 하다보면 정적 컨텐츠가 캐시돼 컨텐츠를 변경해도 내용이 바뀌지 않는 경우가 종종 발생한다. 이 때는 브라우저의 캐시를 지워주면 다시 컨텐츠를 조회하기 위해 서버로 요청을 보내게 된다.(F12누르고 새로고침 오른쪽 누르는 거)
  • GET을 통해 서버에 리소스를 요청할 때 웹 캐시가 요청을 가로채 서버로부터 리소스를 다시 다운로드하는 대신 리소스의 복사본을 반환한다. HTTP 헤더에서 cache-control 헤더를 통해 캐시 옵션을 지정할 수 있다.

www.example-url.com/resources?name1=아무개&name2=곽철용

쿼리스트링을 포함한 URL입니다. 파라미터인 name1과 name2를 통해 값을 전달받을 수 있다.만약, 요청 파라미터가 여러 개이면 &로 연결한다.

---

query
: 문의하다, 질문하다라는 뜻이라고 한다. 그리고 프로그래밍에서 이러한 문의는 요청, 즉 '데이터베이스에 정보를 요청하는 일'을 말한다. 그렇게 때문에 정보를 처리하는 과정에서 query를 보내면 이에 따른 정보를 DB로부터 가져온다.

DB용 언어를 SQL이라고 하는데, DB에서 query는 원하는 조건에 맞는 데이터를 조작할 수 있는 SQL 문장의 집합을 말하며, 질의문이라 한다.

DB서버가 구동이 되고 있는 환경에서(Oracle, Cubrid, MsServer, MySQL, Tibero, Altibase 등) DB에 대해 명령문을 작업하게 되는데 이 때의 명령문을 쿼리(Query)라고 생각하면 됩니다.

---

URL 파라미터(쿼리 파라미터)
: 파라미터는 번역하면 '매개변수'라고 불린다. IT업계에서는 ‘소프트웨어나 시스템상의 작동에 영향을 미치며, 외부로부터 투입되는 데이터’라는 의미로 통용되고 있다.

파라미터는 쿼리 스트링이라고도 하며, 정보에 따라서 페이지의 콘텐츠가 가변적일 수 있을 때 많이 사용한다.

URL파라미터란 위 URL 중에서 물음표 ‘?’ 이후 문자열을 뜻한다.

URL 파라미터는 ‘웹 서버에 저장된 프로그램을 웹 브라우저로 전달하는 것’이라고 이해할 수 있다.

[파라미터 명]=[파라미터 값]이 한 세트로 작동하고, 파라미터가 여러 개 일 때는 마찬가지로 위에 빨갛게 마킹해 둔 것처럼 ‘&’로 이어줍니다.

---

POST

• 리소스를 생성/업데이트하기 위해 서버에 데이터를 보내는 데 사용됩니다.
  • GET과 달리 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송한다. 
  • 메시지 바디를 통해 서버로 요청 데이터 전달해서 서버는 요청 데이터를 처리한다.
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
  • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
  • 그 Body의 타입은 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시 따라 결정 된다.
    • Content-Type의 종류로는 application/x-www-form-urlencoded, text/plain, multipart/form-data 등이 있다
    • 데이터 타입을 표시하지 않으면 서버는 내용이나 URL에 포함된 리소스의 확장자명 등으로 데이터 타입을 유추한다.
    • 만약, 알 수 없는 경우에는 application/octet-stream로 요청을 처리한다.
  • POST는 데이터가 Body로 전송되고 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있지만, POST 요청도 크롬 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인할 수 있기 때문에 민감한 데이터의 경우에는 반드시 암호화해 전송해야 한다.
• POST 요청에는 데이터 길이에 대한 제한이 없다.
  •  POST 요청은 GET과 달리 대용량 데이터를 전송할 수 있다.
• POST 요청은 브라우저 기록에 남아 있지 않는다.
• POST 요청을 북마크에 추가할 수 없다.
• POST 요청은 캐시되지 않는다.
• URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다.(정해진 것이 없음)

---

• 주로 새 리소스 생성(등록) : 서버가 아직 식별하지 않은 새 리소스 생성
• 요청 데이터 처리 : 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우 / POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
• 다른 메서드로 처리하기 애매한 경우 (ex. JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우)

---

GET 과 POST 의 차이점 

• 사용목적 : GET은 서버의 리소스에서 데이터를 요청할 때, POST는 서버의 리소스를 새로 생성하거나 업데이트할 때 사용한다.
• 요청에 body 유무 : GET 은 URL 파라미터에 요청하는 데이터를 담아 보내기 때문에 HTTP 메시지에 body가 없다. POST 는 body 에 데이터를 담아 보내기 때문에 당연히 HTTP 메시지에 body가 존재한다.
• 멱등성 (idempotent) : GET 요청은 멱등이며, POST는 멱등이 아니다.

멱등이란?

멱등의 사전적 정의는 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.
GET은 리소스를 조회한다는 점에서 여러 번 요청하더라도 응답이 똑같을 것 이다. 반대로 POST는 리소스를 새로 생성하거나 업데이트할 때 사용되기 때문에 멱등이 아니라고 볼 수 있다. (POST 요청이 발생하면 서버가 변경될 수 있다.)