Foundation 1- Server Communications ; Http (대표님) **

프론트가

물리적으로 떨어져있는 나의 백엔드 웹브라우저까지 와야 하는데 

 

백엔드에 요청하고 받아야 하는데

물리적으로 멀리 떨어져잇는 서버에 요청해야하는데 이 통신이 어떻게 이루어지는가 

 

 

학습목표

1. 서버간의 통신이 어떻게 이루어지는지 이해한다.
2. 개발자로서 서버간의 통신 방법을 왜 배워야 하는지 이해한다.
3. 대표적인 서버 통신 방법인 HTTP의 특징을 인지하고작동원리를 이해한다.
4. HTTP를 사용해 Backend API를 개발하는데 가장 좋은 방법중 하나인 RESTful API에 대해 이해한다.

---

통신

서버 간의 통신이 어떻게 이루어지는가 

 

오프라인 커피 구매

→ 서로 같은 언어를 쓰기 때문에 (양자가 서로 이해할 수 있는 공통의 목소리, 성대를 통해 ) → 소통 

--> 주체: 사람, 사람

 

온라인에서 커피 구매

(웹서비스에서는 웹브라우저와 server 간의 소통, 인터넷을 통해_인터넷 기반으로 문자text를 주고받으면 소통 ) 

→ 주체 : 클라이언트(매개체 - 웹브라우저, 모바일 앱), 서버 

---

서버란

서버는 단독으로 움직이지 X

불특정 다수의 컴퓨터에 일방적으로 서비스를 제공 X 

 

서버는 클라이언트로부터 요청(Request)를 받아야 비로소 처리를 시작하여 서비스를 제공

 

1. 웹 브라우저가 웹 서버에게 'www.naver.com' 사이트 데이터를 달라고 요청

2. 웹 서버는 해당 사이트의 파일을 찾음

3. 웹 서버는 찾은 파일을 웹 브라우저에게 반환

4. 웹 브라우저는 파일을 받아 네이버 메인을 화면에 표시

 

• 서버 : 클라이언트에게 네트워크 통해, 정보/서비스 제공하는 컴퓨터 시스템 (= 컴퓨터 프로그램/ 장치)

서비스를 제공하는 소프트웨어가 실행되는 컴퓨터

클라이언트에게 요청 받아, 응답 내려줌 

• 클라이언트: 서비스를 사용하는 컴퓨터 (웹에 접근하는 소프트웨어/ 서버에 요청 보내고, 응답 받는 역할) 서버에 데이터 요청하고, 응답 받음

• 서비스:  컴퓨터가 인터넷이라는 하나의 거대한 네트워크 구성 (인터넷 통해 다양, 방대한 데이터 공유) 네트워킹; 2대 이상의 컴퓨터를 케이블로 연결하여 네트워크 구성하는 것

 

---

 

언어 = set of rules(규칙) – 같은 언어로 소통한다는건 그 규칙을 이해한다는 뜻

 

서버에서의 언어, 정해진 규칙=  프로토콜

서버는 정해진 규칙, 프로토콜로 소통한다! 

 

Http, ftp 등등 있는데 우리는 

http만 배우면 된다 

---

HTTP

Hyper text : 문서, 문서 링크로 연결되어있다 뜻

Transfer: 보낸다, 전달

Protocol : 정해진 규칙, 

 

= 서버끼리 전달하는 규칙

 

클라이언트: http규칙에 맞게 서버에 보냄  by 인턴세

서버도 http 규칙에 맞게 정해진 문자열text을 보냄 by 인터넷

 

Cf. Tim Berners lee (world wide web의 아버지) 

Http, html .url (주소) inverter 다 발명함 → world wide web 생김 (www)

 

• Html을 서버끼리 주고 받을 수 있게 만든 protocol = http 
• 주소 처럼 사람이 직관적으로 이해할 수 잇는 구조가 필요하다 = url 

 

HTTPS 

Http 규격에 맞춘 문자열로 전달되는데, 단순 문자열이기 때문에 중간에 가로챌 수 있다. 

보안 취약점 있음 - 문자열을 보내는 것이다보니, 누가 중간에 가로채면 내 아이디 비번을 누가 알게 되는 것

 

Ex. 말로 이야기 하는데 중간에 말을 누가 들으면 전파되는거처럼

 

그래서 http를 암호화 시킨 것

서로 소통하는 두 주체만 알 수 있도록 

암호화돼서 제3자는 알 수 없음. 

Http + ssl = https 

 

보안 중요한건 거의 이거 사용

 

---

 

http를 알아야 http를 베이스로 하는 걸 만들수 잇다 

 

http 두가지 특징 

1. request/ response 

소통 = 요청 + 응답 

요청하는 주체: client 

응답하는 주체: server / host 

• 요청이 시작점, 응답이 그 다음
• 요청 받으면 무조건 해줘야 함. 안하면 에러

2. Stateless :http는 상태가 없다 

Http 개별 통신은 모두 독립(자기만 안다) / 과거 http 통신 결과/상태를 보존 안 함 (지금 이 순간의 소통만 안다. 과거에 소통이 있었는지 없었는지 모른다) 

Ex. 내가 로그인을 하는데, http는 내가 이전에 로그인 통신이 있었는지를 모른다. 

 

그 전의 요청 사항을 모름. 

두번째 대화를 하더라도. 

 

오프라인 카페에서는, 매번 시럽 추가 해달라 하면 기억하지만, http는 모른다. 

해당 대화만 안다. 그외 정보는 아예 안 갖고 있다. 

 

그렇기 떄문에 요청을 할때마다 처음의 정보를 모든 걸 다 가져간다. 

아이스 아메리카노 얼마에요?

 

아이스 아메리카노 얼마에요?

시럽 2개 넣어주세오 

아이스아메리카노 얼마에요?

시럽 2개 넣어주세요

얼음 빼주세요 

 

로그인

 

로그인

클릭

 

로그인

클릭

마이페이지

 

이렇게 다 정보를 가져가야 함. 그래야 로그인인줄 안다. 이기 그 전인데도, 로그인 정보가 없으면 로그인 안 한 줄 앎(비밀번호 아이디를 매번 정하면 안되니, 민감한 정보는 암호화/토큰화 시켜서 보냄: 인가 인증) 

 

모든 정보를 다 담아서 요청한다! 

 

---

Http 메세지 종류 

1. Request
2. Respone 

---

1.  Request 메세지 구조 

1. Start line 요청의 첫번째 줄 3개  ex.POST/login HTTP/1.1

1. Http method로 표현 → 요청이 의도한 액션 (get으로 시작:  달라는거니까/ 블로그 썼다. Post 생성)
2. Request target: 요청이 들어가는 상세주소/ 요청이 전송되는 목표 url 

= 상세주소 (테헤란로 427)

Cf. naver.com 은 주소가 아님 (서울시) 

 

1. Http version  명시 : keep updating 되니 현재 사용하는 버전 명시 

2. Headers 요청 자체에 대한 메타 데이터 

• {key:value} 형태
• Headers: {

Host: www. 실제도메인 주소 (서울시)    → host + request target 합치면 정확힌 주소 나옴

content-type: application/json    → jsontpye로 보내고 있다, 너도 jsontype로 처리해야해 

Content-length: 50

}

 

3. Body: 요청 실제 내용 

 

보낸 데이터 없ㅇ르 수도 - 주세요 

생성해주세요  

 

실제주소는 host + request  

---

 

Response 메세지 구조 

1. Status line 

요청에 대한 응답 = 응답에 대한 상태 (요청을 어떻게 처리했는지 알려줘야) 

알려줄게, 안돼, 꺼져 

 

1. Http version : request message와 같음 
2. Status code; 응답상태코드/ 상태를 숫자로 얘기 
3. Status text: 응답상태 간략 설명 텍스트/ 사람도 이해하라고 같은 내용을 텍스트로 알려주는 거 (숫자로 이해하기 어려우니 다시 얘기해주는거)

Ex. HTTP/1.1 404 Not Found 

HTTP/1.1 200 SUCCESS

나머지 두개는 request 메세지 구조와 같음 (start line, status line만 다름)

1. Headers 
2. Body 

 

---

HTTP Request Methods

굉장히 많은 데 자주 쓰이는 3개만 알면 됨 

 

1-1. GET (가져오는거, 읽어오는거 퉁쳐) 간단하게 할수록 좋음

• 정보를 달라

1-2. POST(변화는 post퉁쳐 - delete 안쓰기도)개발자 선택사항 최대한 method 적게 쓰는 방향 

• 데이터를 생성 및 수정할 때 주로 사용하는 메서드이며 대부분의 경우 요청에 body가 포함되어 보내집니다.
• Post put 하기도 (회사마다 다름) delete 안 쓰고 변화있는건 다 post로 퉁치기도

1-3. DELETE

• 서버에서 저장된 특정 데이터를 삭제할 때 사용하는 메서드입니다.

 

---

 

Status Code 

1. Success 정상처리 / status id, text 

200:OK 

201: Created 잘 생성되었어요 

204:No Content 요청을 잘 처리했는데 줄게 없어, 되돌릴 건 없어 

 

많은데 3개, 근데 이것도 200: OK로 퉁칠 수도(회사의 개발팀이 결정하기나름, trend는 simple하게 개발 쉽게 하는거  

1. Error 에러 요청하는 주체가 잘못 주체 

• 400: Bad Request 너가 지금 요청을 잘못했다. (데이터 빼먹고 보낸거. id/pw해달라했는데 id/pw가 없는거
• 401: Unauthorized 권한 - 로그인이 돼어야만 가능한거 (로그인 먼저해야해)
• 403: Forbidden 권한 - 로그인 됐더라도 권한 없을 수도 (무료 유저가 유료 결제 컨텐츠 접근시) “당신은 권한이 없습니다)/ admin만 볼 수 있는거
• 404: Not Found 요청한 url 존재하지 않는다 (서버로 연결은 됨, 이런 주소 데이터 없어)

서버를 못 찾은거랑 다름

 

1. Server Error 서버에서 에러가 나서 처리 못할 때 

500: Internal Server Error 

요청 자체를 보고 문맥 이해할 수 있게 http 규칙에 맞게 한 거 

Restful api 

주어진 요청 보고, http 규칙에 맞게 해석하면 됨 

•  명사 → 주소 

• 동사 → method ‘생성한다. 수정한다' 
• 실제 데이터 → body 

---

 

///////학습자료

 

---

1. HTTP

HTTP는 컴퓨터들끼리 HTML 파일을 주고받을 수 있도록 하는 소통 방식 또는 약속입니다. 또, HTTP는 웹에서 이뤄지는 모든 데이터 교환의 기초이며 클라이언트와 서버 프로토콜

1-1. HyperText

먼저, HTTP에서 HT는 HyperText를 뜻합니다. 문서와 문서가 링크로 연결되도록 하는 태그로 구성된 언어를 뜻하는 HTML(HyperText Markup Language)의 HyperText와 의미가 동일합니다.

1-2. Transfer

다음으로 HTTP의 T는 Transfer를 뜻합니다. Transfer는 사전적 의미로 "전송하다"라는 의미를 가집니다. 우리가 만든 웹사이트를 널리 알리고 다른 사람들과 공유하기 위해서 다른 컴퓨터에게 전송을 해야 하는데 여기에서 전송은 보내는 주체와 받는 주체가 있다는 것이 특징이기도 합니다.

1-3. Protocol

마지막으로 P는 Protocol을 뜻합니다. 프로토콜은 협약, 통신 규약이라는 의미를 가집니다. 물리적으로 떨어진 컴퓨터끼리 어떻게 HTML 파일(HyperText)을 주고받을지에 대한 약속입니다.

예시로 우리는 한국인으로 태어나 한국어를 사용하는 사회에 살고 있습니다. 한국에서의 소통 방식(약속)인 한국어로 소통을 하듯 컴퓨터도 컴퓨터끼리의 소통 방법이 필요합니다. 이런 필요에 의해서 만들어진 소통하는 방식 또는 약속이 HTTP입니다. 즉, 우리가 사용하는 인터넷상에서 일어나는 소통은 대부분 HTTP 규약

2. HTTP의 특징

---

2-1. Request(요청) / Response(응답)

HTTP의 특징 첫 번째는 요청과 응답입니다. 우리에게 익숙하고 친숙한 소통 방식이 컴퓨터의 소통 방식에도 적용이 된 것입니다.

앞서 HTTP의 키워드인 Transfer에 대해서 설명할 때, 전송은 보내는 주체와 받는 주체가 있다고 했습니다. 보내는 주체는 받는 주체에게 요청을 보내고, 받는 주체는 요청을 보낸 주체에게 응답을 보냅니다. 예시로 영상을 보기 위해 썸네일을 클릭한다면 서버에게 요청을 보내는 것이고 서버는 이 요청을 처리해서 클라이언트에게 영상 제공으로 응답하는 것입니다.

2-2. Stateless

HTTP의 특징 두 번째는 Stateless입니다. 문자 그대로 번역하면 State(상태) + less(없음) 을 의미합니다. 상태가 없다는 것은 기억력이 없다는 의미이기도 합니다.

각각의 HTTP 통신(요청/응답)은 독립적이기 때문에 과거의 통신 내용을 전혀 기억하지 못합니다. 비유를 하자면, 이미 자기소개를 한 사람에게 계속해서 똑같은 내용으로 자기소개를 해야 하는 것과 같습니다. 그러므로 이를 해결하기 위해서는 매 통신마다 필요한 모든 정보를 담아서 요청을 보내야 합니다.

그리고 온라인 쇼핑몰에서 로그인 후 장바구니 페이지로 이동하는 등의 연속된 요청과 응답을 통한 데이터 처리가 필요한 경우를 위해 로그인 토큰 또는 브라우저의 쿠키, 세션, 로컬 스토리지 같은 기술이 필요에 의해 만들어졌습니다.

3. HTTP 메시지 구조

---

HTTP를 통한 요청과 응답을 할 때 메시지 구조가 있습니다. 그리고 이를 활용하여 프론트엔드는 백엔드에게 데이터를 요청하고 백엔드는 요청을 처리해서 응답을 합니다. 요청과 응답에 메시지 구조를 잘 파악한다면 대부분의 에러를 잡아내며 원활한 통신을 할 수 있습니다.

3-1. Request 메시지 구조

HTTP에서 요청은 프론트엔드(클라이언트)에서 백엔드(서버)에 일(데이터 처리)을 시작하게 하기 위해 보내는 메시지입니다. 요청은 메시지이고 이 메시지의 구조는 크게 세 부분으로 구성되어 있습니다.

 

3-1-1. Start Line

• 요청의 첫 번째 줄에 해당하고 글의 제목과 같은 역할을 합니다.

3-1-2. Headers

• 해당 요청에 대한 메타 데이터(추가 정보)를 담고 있는 부분입니다.

3-1-3. Body

• 해당 요청의 실제 내용이며 요청 메서드에 따라 내용이 없을 수도

 

3-2. Response 메시지 구조

응답도 요청과 마찬가지로 메시지 입니다. 그리고 응답 메시지 구조 역시 크게 세 부분으로 구성되어 있습니다.

3-2-1. Status Line

• 응답의 첫 번째 줄에 해당하고 요청에 대한 처리 상태를 클라이언트에게 알려 줍니다.

3-2-2. Headers

• 요청의 헤더와 동일하며 응답의 추가 정보(메타 데이터)를 담고 있는 부분입니다.
• 다만, 응답에서만 사용되는 헤더의 정보들이 있습니다.

3-2-3. Body

• 일반적으로 요청의 Body와 동일합니다.
• 요청의 경우 메서드에 따라 Body가 존재하지 않듯이 응답도 응답 형태에 따라 데이터를 전송할 필요가 없는 경우 Body가 없을 수 있습니다.
• 가장 많이 사용되는 Body의 데이터 타입은 JSON(JavaScript Object Notation) 입니다.

HTTP Methods

 

1. HTTP Request Methods

---

굉장히 많은 데 자주 쓰이는 3개만 알면 됨 

HTTP 메서드는 클라이언트가 웹 서버에게 사용자 요청의 목적이나 종류를 알리는 수단입니다. 초기 HTTP에서는 메서드가 GET 하나밖에 없었지만 이후 다양한 메서드들이 생겨났습니다.

이번 시간에는 다양한 메서드들 중 자주 사용되는 세 가지 메서드를 소개하겠습니다. 또, 메서드 각각의 이름과 특징을 보다 직관적으로 이해하기 위해 애플 홈페이지에서 쇼핑을 하는 상황으로 진행하겠습니다.

1-1. GET (가져오는거, 읽어오는거 퉁쳐) 간단하게 할수록 좋음

• 정보를 달라
• 웹 페이지에 접속해서 필요한 데이터를 서버로부터 받아올 때 사용하는 메서드이며 가장 간단하고 많이 사용됩니다.

1-2. POST(변화는 post퉁쳐 - delete 안쓰기도)개발자 선택사항 최대한 method 적게 쓰는 방향 

• 데이터를 생성 및 수정할 때 주로 사용하는 메서드이며 대부분의 경우 요청에 body가 포함되어 보내집니다.
• Post put 하기도 (회사마다 다름) delete 안 쓰고 변화있는건 다 post로 퉁치기도

1-3. DELETE

• 서버에서 저장된 특정 데이터를 삭제할 때 사용하는 메서드입니다.

 

Response Status Code

---

응답 상태 코드는 요청이 어떻게 되었는지 알려줍니다. 응답 상태 코드는 여러 개의 그룹으로 나뉘고 상태 코드의 숫자에는 각각 의미가 내포되어 있어서 이것만 보고도 응답의 성공 여부를 파악할 수 있습니다.

이번 시간에는 자주 사용하고 보게 되는 응답 그룹 3개와 상태 코드를 소개하겠습니다.

1. Successful responses

1-1. 200: OK

• 요청에 대한 처리가 백엔드 서버에서 성공적으로 되었을 때의 상태 코드입니다.

1-2. 201: Created

• 요청이 성공적이고 그 결과로 새로운 리소스가 생성되었을 때의 상태 코드입니다.
• 일반적으로 POST, PUT 요청 이후에 사용됩니다.

1-3. 204: No Content

• 요청이 성공했으며 제공할 응답 메시지가 없을 경우의 상태 코드입니다.
• 주로 DELETE 요청으로 리소스가 성공적으로 삭제되고 응답으로 제공할 콘텐츠가 없을 경우 사용됩니다.

2. Client error responses

2-1. 400: Bad Request

• 해당 요청이 잘못되었을 때의 상태 코드입니다.
• 주로 요청의 Body의 내용이 잘못되었을 때 사용됩니다.

2-2. 401: Unauthorized

• 유저가 해당 요청을 진행하려면 먼저 로그인을 하거나 회원가입이 필요하다는 의미에 상태 코드입니다.

2-3. 403: Forbidden

• 유저가 해당 요청에 대한 권한이 없다는 의미를 나타내는 상태 코드입니다.
• 접근 불가능한 정보에 접근했을 경우에 사용됩니다.

2-4. 404: Not Found

• 요청된 URI 가 존재하지 않는다는 의미를 나타내는 상태 코드입니다.

3. Server error responses

3-1. 500: Internal Server Error

• 서버에서 에러가 났을 때 사용 되는 상태 코드입니다.