HTTP 설명(인터넷에서 데이터를 주고 받게하는 프로토콜), get, post 차이

인터넷 != WWW(World Wide Web)
WWW는 인터넷 기반의 대표 서비스 중 하나
물리적인 하나의 컴퓨터에는 여러개의 서버가 동작가능
각 각의 서버들은 포트라는 값으로 구분되서 동작(웹은 80번, 이메일은 25번 포트 사용 등..)
인터넷이란 네트워크들의 네트워크라 말할 수 있음.

 https://velog.io/@sujeong/2-%EC%9B%B9%EC%9D%98-%EB%8F%99%EC%9E%91-HTTP-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%9D%B4%ED%95%B4

1-1-2. 웹의 동작 (HTTP 프로토콜 이해)

 

HTTP (HyperText Transfer Protocol)

텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜이다.

서버-클라이언트 모델을 따르는 프로토콜

 

이렇게 규약을 정해두었기 때문에 모든 프로그램이 이 규약에 맞춰 개발해서 서로 정보를 교환할 수 있게 되었다.

 

데이터를 주고 받을 때,(데이터는 html이 될 수도, 다른 것이 될수도 있음. 메소드는 생략되어있으면 기본 get임) 사용하는 프로토콜.

 

프론트엔드와 백엔드가 데이터를 주고 받을 때에도 이것을 사용!!!

클라이언트(프론트엔드가 됨)가 HTTP REQUEST (요청 API), 서버(백엔드가 됨)는 RESPONSE(응답 API)

 

api:

각각의 요청들을 담당하는 서버에게 요청이 잘 전달 및 처리될 수 있도록 교통정리를 해주는 "체계"가 바로 API입니다.

"어떠한 방식으로 정보를 요청해야 하는지, 그리고 그러한 요청을 보냈을 때 어떠한 형식으로 무슨 데이터를 전달받을 수 있는지"에 대해 정리한 일종의 규격이라고 볼 수 있습니다. 

 

사람이 대화를 하기 위해서는 같은 언어와 같은 문법으로 대화를 해야 하는게 기본적인 규칙이다.
아버지가방에들어간다. 와 아버지가 방에 들어간다 는 다른것 처럼 말이다.
즉 먼저 이 두 환경간에 '통신'이라는 커뮤니케이션을 해야한다. 

이때 필요한 규약(문법, 약속 등등)이 있는데 이것이 통신규칙 이라고 하며 이것을 http(hyper text transfer protocol)라고 한다.

 

일반적으로 클라이언트(프론트엔드)가 http request(요청, API(application programming interface))을 보내게 되면 서버(백엔드)에서 http response(응답)을 하는 형태가 된다. 

 

https://chicode.tistory.com/75

 

 

 프론트엔드와 백엔드가 소통하는 엔드포인트, restful api

https://evan-moon.github.io/2020/04/07/about-restful-api/

 

=> 이러한 인터넷의 클라이언트 서버간의 통신을 위한 규칙 -> HTTP,

HTTP를 더 잘 활용하기 위해서 만들어진 것이 RESTful api(하지만 꼭 restful api를 위해서 http가 필요한 것은 아님. restful은 아키텍처, http는 규약=설계지침, WAP, WebRTC, MQTT 등 다른 프로토콜로도 이용 가능하다. 근데 대부분이 http임.)

api의 효율을 높이기 위해 만든 하나의 약속

 

기본적으로 웹 페이지에서 할 수 있는 행동은 정보를 눈으로 보는것, 그것을 입력하는것, 수정, 삭제하는것 총 4가지 정도의 행동으로 볼 수 있다.
이런 행동을 하기 위해 서버에 미리 우리의 행동을 전달해 주면 훨씬 좋지 않을까? 라는 기반을 바탕으로 method라는 것을 만들어 미리 처리할 수 있도록 만들어 준다.

 

HTTP 동작

클라이언트 즉, 사용자가 브라우저를 통해서 어떠한 서비스를 url을 통하거나 다른 것을 통해서 요청(request)을 하면 서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 응답(response)하는 형태로 동작한다.

• 요청 : client -> server
• 응답 : server -> client

HTML 문서만이 HTTP 통신을 위한 유일한 정보 문서는 아니다.
Plain text로 부터 JSON 데이터 및 XML과 같은 형태의 정보도 주고 받을 수 있으며, 보통은 클라이언트가 어떤 정보를 HTML 형태로 받고 싶은지, JSON 형태로 받고 싶은지 명시해주는 경우가 많다.

HTTP 특징

• HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해 해석이 된다.
• TCP/ IP를 이용하는 응용 프로토콜이다.
  (컴퓨터와 컴퓨터간에 데이터를 전송 할 수 있도록 하는 장치로 인터넷이라는 거대한 통신망을 통해 원하는 정보(데이터)를 주고 받는 기능을 이용하는 응용 프로토콜)
• HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다.
  (이러한 단점을 해결하기 위해 Cookie와 Session이 등장하였다.)
• HTTP는 연결을 유지하지 않는 프로토콜이기 때문에 요청/응답 방식으로 동작한다.

예시로 알아보는 HTTP

• 서버 : 어떠한 자료에 대한 접근을 관리하는 네트워크 상의 시스템 (요청에 대한 응답을 보내준다.)
• 클라이언트 : 그 자료에 접근할 수 있는 프로그램
  Ex) 웹 브라우저, 핸드폰 어플리케이션 등...

클라이언트 프로그램에서 사용자가 회원가입을 시도하게 되면, 서버로 회원정보를 보내게 되고 서버는 회원 정보를 저장해주기도 한다. 이 과정에서 클라이언트와 서버 간의 교류가 HTTP라는 규약을 이용하여 발생하게 된다.

Request (요청)

클라이언트가 서버에게 연락하는 것을 요청이라고 하며 요청을 보낼때는 요청에 대한 정보를 담아 서버로 보낸다.

예시로 알아보는 Request

서버가 주문서를 받아 클라이언트가 어떤 것을 원하는지 파악할 수 있게 한다. 이처럼 요청은 식당에서 주문서를 작성하는 것과 같다고 생각하면 된다.

Request Method (요청의 종류)

• GET : 자료를 요청할 때 사용
• POST : 자료의 생성을 요청할 때 사용
• PUT : 자료의 수정을 요청할 때 사용
• DELETE : 자료의 삭제를 요청할 때 사용

 

Get은 가져온다는 개념이고, Post는 수행한다는 개념으로 받아들이면 쉽습니다.

https://velog.io/@songyouhyun/Get%EA%B3%BC-Post%EC%9D%98-%EC%B0%A8%EC%9D%B4%EB%A5%BC-%EC%95%84%EC%8B%9C%EB%82%98%EC%9A%94

Get과 Post의 차이를 아시나요?

주요 메소드 5가지

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

GET은 보통 리소스를 조회할 때 사용하며, 서버에 전달하고 싶은 데이터는 query를 통해서 전달한다. 메시지 바디를 사용해서 데이터를 전달할 수는 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다. 헤더를 사용

GET 요청은 캐시가 가능하다. 

 : GET을 통해 서버에 리소스를 요청할 때 웹 캐시가 요청을 가로채 서버로부터 리소스를 다시 다운로드하는 대신 리소스의 복사본을 반환한다. HTTP 헤더에서 cache-control 헤더를 통해 캐시 옵션을 지정할 수 있다.

 

• GET 요청은 브라우저 히스토리에 남는다.
  
  
• GET 요청은 북마크 될 수 있다.
  
  
• GET 요청은 길이 제한이 있다.
•  : GET 요청의 길이 제한은 표준이 따로 있는건 아니고 브라우저마다 제한이 다르다고 한다. 
  
  
• GET 요청은 중요한 정보를 다루면 안된다. ( 보안 )
•  : GET 요청은 파라미터에 다 노출되어 버리기 때문에 최소한의 보안 의식이라 생각하자.
  
  
• GET은 데이터를 요청할때만 사용 된다.

출처: https://noahlogs.tistory.com/35

[네트워크] get 과 post 의 차이

 [인생의 로그캣]

 

 

Get과 Post의 차이점

위 사진은 Get과 Post의 리소스 전달 방식의 차이를 표현한 사진입니다.

GETPOST

캐시	⭕️	❌
브라우저 기록	⭕️	❌
북마크 추가	⭕️	❌
데이터 길이 제한	⭕️	❌
HTTP 응답 코드	200(Ok)	201(Created)
언제 주로 사용하는가?	리소스 요청	리소스 생성
리소스 전달 방식	쿼리스트링	HTTP Body
idempotent	⭕️	❌

 

POST는 데이터 요청을 처리하고, 메시지 바디를 통해 서버로 데이터를 전달한다. 주로 신규 리소스를 등록하거나 프로세스 처리에 사용된다.

 

POST는 클라이언트에서 서버로 리소스를 생성하거나 업데이트하기 위해 데이터를 보낼 때 사용 되는 메서드다. 예를들면 게시판에 게시글을 작성하는 작업 등을 할 때 사용할 된다.

POST는 전송할 데이터를 HTTP 메시지 body 부분에 담아서 서버로 보낸다. ( body 의 타입은 Content-Type 헤더에 따라 결정 된다.)

GET에서 URL 의 파라미터로 보냈던 name1=value1&name2=value2 가 body에 담겨 보내진다 생각하면 된다.

POST 로 데이터를 전송할 때 길이 제한이 따로 없어 용량이 큰 데이터를 보낼 때 사용하거나 GET처럼 데이터가 외부적으로 드러나는건 아니라서 보안이 필요한 부분에 많이 사용된다. 

( 하지만 데이터를 암호화하지 않으면 body의 데이터도 결국 볼 수 있는건 똑같다. )

POST를 통한 데이터 전송은 보통 HTML form 을 통해 서버로 전송된다. 

 

 

• POST 요청은 캐시되지 않는다.
  
  
• POST 요청은 브라우저 히스토리에 남지 않는다.
  
  
• POST 요청은 북마크 되지 않는다.
  
  
• POST 요청은 데이터 길이에 제한이 없다.

 

 

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

출처: https://noahlogs.tistory.com/35 [인생의 로그캣]

 

[네트워크] get 과 post 의 차이

PUT은 리소스가 있으면 대체하고 리소스가 없으면 생성한다. 쉽게 말해 데이터를 덮어쓴다.

PATCH는 PUT과 마찬가지로 리소스를 수정할 때 사용하지만, PATCH는 리소스를 일부분만 변경할 수 있다.

DELETE는 리소스를 제거할때 사용한다.

 

HTTP 메소드의 속성

HTTP 메소드의 속성에는 안전(Safe Methods), 멱등(Idempotent Methods), 캐시가능(Cacheable Methods)가 있다.

다음 단어가 무엇을 의미하는지 살펴보도록 하자.

1. 안전(Safe Methods)
2. 이 말은 계속해서 메소드를 호출해도 리소스를 변경하지 않는다는 뜻이다. 주요 메소드중에는 GET 메소드가 안전하다고 볼 수 있다.
3. 멱등(Idempotent Methods)
4. 이 말은 메소드를 계속 호출해도 결과가 똑같다는 뜻이다. Get, PUT, DELETE는 멱등하다고 볼 수 있지만 POST나 PATCH는 멱등하다고 볼 수 없다.
5. 캐시가능(Cacheable Methods)
6. 캐시가능하다는 말은 말 그대로 캐싱을 해서 데이터를 효율적으로 가져올 수 있다는 뜻이다. GET, HEAD, POST, PATCH가 캐시가 가능하지만 실제로는 GET과 HEAD만 주로 캐싱이 쓰인다고 한다.

이를 토대로한 http 메소드를 다음의 표와 같이 요약할 수 있다.

이 외에도 보통 이러한 메소드는 적절한 uri 설계와 같이 이루어 지는데 restful api 설계방식을 보통 따르곤한다. 이에 대한 uri 설계 가이드도 한번 보면 좋을 것 같다.

 

https://kyun2da.dev/CS/http-%EB%A9%94%EC%86%8C%EB%93%9C%EC%99%80-%EC%83%81%ED%83%9C%EC%BD%94%EB%93%9C/

http 메소드와 상태코드

4. HTTP 메시지 구조

-      Header + Body로 나누어 진다.
-      Header에는 주소 정보, 어떤 메서드 방식을 썼는지, 클라이언트 정보, 브라우저 정보, 접속 URL 등의 정보를 담는다.
-      Body에는 보통 비어 있다가 필요시 데이터 정보가 포함된다. 

---

 

1. Request 객체

 

-       클라이언트에서 어떤 페이지를 요청하면 서버로 요청 정보를 전송하는데, 이렇게 전송된 데이터가 저장되는 곳이 Request 객체이다. 사용자가 브라우저를 통해 서버에게 어떤 요구를 하면 Request 객체는 이때 사용자의 브라우저 정보나 입력한 값 등의 정보를 갖게 된다.
 

2. Response 객체

-       사용자가 어떤 요청을 하였을 때, 서버가 이에 응답을 보내려고 Response 객체를 사용한다.

 

https://kyun2da.dev/CS/http-%EB%A9%94%EC%86%8C%EB%93%9C%EC%99%80-%EC%83%81%ED%83%9C%EC%BD%94%EB%93%9C/​

Request HTTP 메시지 예시

GET https://velog.io/@surim014 HTTP/1.1								// 시작줄
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...			  // 헤더
Upgrade-Insecure-Requests: 1

1. 시작줄 (첫 줄)

첫 줄은 시작줄로 메서드 구조 버전으로 구성되었다.

• GET : HTTP Method
• https://velog.io/@surim014 : 사이트 주소
• HTTP/1.1 : HTTP 버전

2. 헤더 (두 번째 줄부터)

두번째 줄부터는 헤더이며 요청에 대한 정보를 담고 있다. User-Agent, Upgrade-Insecure-Requests 등등이 헤더에 해당되며 헤더의 종류는 매우 많다.

3. 본문 (헤더에서 한 줄 띄고)

본문은 요청을 할 때 함께 보낼 데이터를 담는 부분이다. 현재 예시에는 단순히 주소로만 요청을 보내고 있고 따로 데이터를 담아 보내지 않기 때문에 본문이 비어있다.

 

Response (응답)

서버가 요청에 대한 답변을 클라이언트에게 보내는 것을 응답이라고 한다.

Status Code (상태 코드)

상태 코드에는 굉장히 많은 종류가 있다. 모두 숫자 세 자리로 이루어져 있으며, 아래와 같이 크게 다섯 부류로 나눌 수 있다.

• 1XX (조건부 응답) : 요청을 받았으며 작업을 계속한다.
• 2XX (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.
• 3XX (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
• 4XX (요청 오류) : 클라이언트에 오류가 있음을 나타낸다.
• 5XX (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.

Resonse HTTP 메시지 예시

HTTP/1.1 200 OK														// 시작줄
Connection: keep-alive												 // 헤더
Content-Encoding: gzip												 
Content-Length: 35653
Content-Type: text/html;

<!DOCTYPE html><html lang="ko" data-reactroot=""><head><title...

1. 시작줄 (첫 줄)

첫 줄은 버전 상태코드 상태메시지로 구성되어 있다. 200은 성공적인 요청이었다는 뜻이다.

2. 헤더 (두 번째 줄부터)

두 번째 줄부터는 헤더로 응답에 대한 정보를 담고 있다.

3. 본문 (헤더 뒤부터)

응답에는 대부분의 경우 본문이 있다. 보통 데이터를 요청하고 응답 메시지에는 요청한 데이터를 담아서 보내주기 때문이다. 응답 메시지에 HTML이 담겨 있는데 이 HTML을 받아 브라우저가 화면에 렌더링한다.

참고 사이트

• VanillaCoding
• zerocho - HTTP
• wikipedia - HTTP state code
• toma0912 - HTTP
• roydest - HTTP

sson

---

GET과 POST방식은 서버에 요청을 하는 메서드이다.
-       클라이언트가 서버에 요청할 때, 제공해야 되는 자원(ID, PW 정보 등)등이 있다면, GET 또는 POST방식을 선택하여 제공한다.
-       GET과 POST의 차이는 보안, 전달형식, 전달할 수 있는 데이터의 량 측면의 차이이다.
 

1. GET 방식 전송

-       데이터에 대한 인수를 URL에 포함하여 전송
-       URL 뒤에 ? 마크를 통해 URL의 끝을 알리고, Key-Valude의 쌍으로 인수 앞에 &을 붙여 구분하며, 글자수는 255자로 제한된다.
-       URL에 포함되기 때문에 HTTP 패킷의 헤더에 포함되어 서버에 요청된다.
-       때문에 HTTP 패킷의 바디는 비어있다.
-       요청 후 멱등성을 가지며, 조작 대상의 자원의 상태를 변화시키지 않아 안정적이다.
-       GET은 캐시가 되는 특징이 있다. (멱등이기 때문에)
-       아이디나 패스워드가 URL에 포함되면 보안에 취약하므로 유의해야 한다.
 

2. POST 방식 전송

-       URL에 요청 데이터를 기록하지 않고, 데이터를 HTTP 바디에 넣어 전송한다.
-       내부의 구분자가 각 파라미터를 구별하여 서버가 해석하므로 속도가 GET에 비해 느리다.
-       데이터 전송에 대한 제한이 없으므로, 글 쓰는 것과 같은 많은 양의 데이터를 전송할 때 사용된다.
-       PUT이나 DELETE 메소드와 같은 역할 수행이 가능하다.
 

3. GET과 POST의 사용

-       GET은 서버에서 어떤 데이터를 가져와서 보여줄 때 사용한다. 주로 조회할 때 사용.
-       즉 서버의 어떤 값이나 내용, 상태 등을 바꾸지 않는 경우에 사용된다.
 
-       POST는 서버의 값이나 상태를 바꾸기 위해서 사용한다.
-       DB에 저장/수정 시에 DB의 값이 변경되게하는 경우에 사용된다.
 

4. GET방식과 POST 방식에 대한 상식

▶ POST 방식이 GET 방식보다 보안 측면에서 더 좋은가?

-       POST든 GET이든 보내는 데이터는 전부 클라이언트측에서 볼 수 있다. 단지 GET 방식은 URL에 데이터가 표시되어 별다른 노력없이 볼 수 있어서지, 두 방식 전부 보안을 생각한다면 암호화 해야한다.
 

▶ GET 방식이 POST 방식보다 속도가 빠른가?

-       빠른건 맞다. 하지만 왜 빠른지를 알아야 하는데, 이유는 GET 방식의 요청은 캐싱 때문에 빠른 것이다.
-       캐싱(Cashing) : 한번 접근 후, 또 요청할 시 빠르게 접근하기 위해 데이터를 저장시켜 놓는 것.

 

 

GET과 POST방식은 서버에 요청을 하는 메서드이다.
-       클라이언트가 서버에 요청할 때, 제공해야 되는 자원(ID, PW 정보 등)등이 있다면, GET 또는 POST방식을 선택하여 제공한다.
-       GET과 POST의 차이는 보안, 전달형식, 전달할 수 있는 데이터의 량 측면의 차이이다.
 

1. GET 방식 전송

-       데이터에 대한 인수를 URL에 포함하여 전송
-       URL 뒤에 ? 마크를 통해 URL의 끝을 알리고, Key-Valude의 쌍으로 인수 앞에 &을 붙여 구분하며, 글자수는 255자로 제한된다.
-       URL에 포함되기 때문에 HTTP 패킷의 헤더에 포함되어 서버에 요청된다.
-       때문에 HTTP 패킷의 바디는 비어있다.
-       요청 후 멱등성을 가지며, 조작 대상의 자원의 상태를 변화시키지 않아 안정적이다.
-       GET은 캐시가 되는 특징이 있다. (멱등이기 때문에)
-       아이디나 패스워드가 URL에 포함되면 보안에 취약하므로 유의해야 한다.
 

2. POST 방식 전송

-       URL에 요청 데이터를 기록하지 않고, 데이터를 HTTP 바디에 넣어 전송한다.
-       내부의 구분자가 각 파라미터를 구별하여 서버가 해석하므로 속도가 GET에 비해 느리다.
-       데이터 전송에 대한 제한이 없으므로, 글 쓰는 것과 같은 많은 양의 데이터를 전송할 때 사용된다.
-       PUT이나 DELETE 메소드와 같은 역할 수행이 가능하다.
 

3. GET과 POST의 사용

-       GET은 서버에서 어떤 데이터를 가져와서 보여줄 때 사용한다. 주로 조회할 때 사용.
-       즉 서버의 어떤 값이나 내용, 상태 등을 바꾸지 않는 경우에 사용된다.
 
-       POST는 서버의 값이나 상태를 바꾸기 위해서 사용한다.
-       DB에 저장/수정 시에 DB의 값이 변경되게하는 경우에 사용된다.
 

4. GET방식과 POST 방식에 대한 상식

▶ POST 방식이 GET 방식보다 보안 측면에서 더 좋은가?

-       POST든 GET이든 보내는 데이터는 전부 클라이언트측에서 볼 수 있다. 단지 GET 방식은 URL에 데이터가 표시되어 별다른 노력없이 볼 수 있어서지, 두 방식 전부 보안을 생각한다면 암호화 해야한다.
 

▶ GET 방식이 POST 방식보다 속도가 빠른가?

-       빠른건 맞다. 하지만 왜 빠른지를 알아야 하는데, 이유는 GET 방식의 요청은 캐싱 때문에 빠른 것이다.
-       캐싱(Cashing) : 한번 접근 후, 또 요청할 시 빠르게 접근하기 위해 데이터를 저장시켜 놓는 것.

 

 

Get의 특성으로 인해 Post랑 혼동해서 잘못 사용할 경우

1. GET 요청은 브라우저에서 캐싱

글을 작성하는 요청인데 GET 방식으로 글내용과 제목을 받아서 서버로 전송한다면, 해당 GET 요청과 그에 대한 응답이 브라우저에 의해 캐쉬가 되었다가 다시 사용될 우려가 있다. 이 경우 캐쉬에 의해 자동으로 동일한 글을 또 작성하는 동작이 서버에서 발생될 수 있는데 이것은 심각한 오류이다.

 

2. 검색봇(크롤러)으로 인한 문제 발생

구글이나 네이버의 검색봇(bot 혹은 crawler)들이 웹페이지 수집을 위해 해당 웹서버에 GET 요청을 할 수 있다. 이때 이러한 봇의 요청에 의해 게시판에 엉뚱한 데이터로 글이 작성되어 올라간다던지, 서버쪽의 데이터가 바뀐다면 당황스러운 일들이 발생할 가능성이 크다.

 

GET, POST의 근본적인 특성 차이는 GET은 idempotent, POST는 non-idempotent 하다는 점이다.

멱등(idempotent)이라는 말이 좀 어려운데, 아래와 같이 풀어서 설명하면 좀 이해가 쉬울것이다.
멱등 연산(idempotent operation)은 수학 용어로 해당 연산을 해도 결과에 변화가 없다는 특성을 표현하는 말이다.
(예: 100 x 1 = 100 이므로, 곱셈에대해 1을 멱등원 이라고 부르며 이러한 1을곱하는 연산이 멱등 연산이다.)

이러한 뜻을 HTTP요청 메서드를 해석하는데 적용해보면,
GET은 해당 요청을 몇번을 수행해도 해당 요청에 대한 결과가 계속 동일하게 돌아오는 것을 의미하며,
POST는 해당 요청이 수행되면 서버에서 무언가 바뀌고, 동일한 결과가 돌아오는 것을 보장할 수 없다는 것을 의미한다.

즉 GET을 이용하여 게시판에 글을 쓴다면(글을 쓴다는 동작은 서버에 데이터가 바뀌고 다른 결과가 돌아 올 수 있다는 것을 의미) 이것은 GET의 idempotent 특성을 무시하는 것이며 문제 발생의 여지가 있다.

 

https://www.letmecompile.com/get-post-%EB%B0%A9%EC%8B%9D-%EC%B0%A8%EC%9D%B4%EC%A0%90/

---

 

 

 

HTTP는 웹 환경에서 정보를 송수신할 때 사용하는 약속이고, REST는 소프트웨어 아키텍처다.

REST에 반드시 HTTP가 필요한 것은 아니다. WAP, WebRTC, MQTT 등 다른 프로토콜로도 이용 가능하다.

REST는 소프트웨어 아키텍처(설계 지침, 원리 등등)고 REST에서 클라이언트-서버 간 통신 시 HTTP를 사용한 것이다.