HTTP 브라우저의 작동원리, REST API

1.  HTTP 브라우저의 작동원리, REST API

 

HTTP  

 

HTTP: HyperText Transfer Protocol

HTML과 같은 문서를 전송하기 위한 프로토콜 // 웹 브라우저와 웹 서버의 소통을 위해 디자인되었다.
특징: Stateless(무상태성)

 

HTTP messages

요청(Requests)  /  응답(Responses)

요청과 응답의 유사한 구조

 

start line: start line에는 요청이나 응답의 상태를 나타낸다 // 첫번째 줄

HTTP headers: 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합이다.

empty line: 헤더와 본문은 구분하는 빈 줄

body: 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함한다. // 선택적으로 사용한다.

이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 한다.

 

HTTP 요청 메소드  ✔️

 

HTTP는 요청 메소드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타낸다 // HTTP 동사라고 부르기도 한다.

 

메소드	설명
GET	특정 리소스의 표시를 요청 // GET을 사용하는 요청은 오직 데이터를 받기만 한다.
HEAD	GET 메소드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않는다.
POST	특정 리소스에 엔티티를 제출할 때 쓰인다 // 이는 종종 서버의 상태의 변화나 부작용을 일으킨다.
PUT	목적 리소스 모든 현재 표시를 요청 payload로 바꾼다.
DELETE	특정 리소스를 삭제한다.
CONNECT	목적 리소스로 식별되는 서버로의 터널을 맺는다.
OPTIONS	목적 리소스의 통신을 설정하는데 쓰인다.
TRACE(en-US)	목적 리소스의 경로를 따라 메시지 loop-back 테스트를 한다.
PATCH	리소스의 부분만을 수정하는데 쓰인다.

 

HTTP 상태 코드  ✔️

 

100 ~ 👇🏻 

100 Continue

지금까지의 상태가 괜찮으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려준다.

101 Switching Protocol

클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 들어가며 서버에서 프로토콜을 변경할 것임을 알려준다.

102 Processing

서버가 요청을 수신했고 이를 처리하고 있지만, 아직 제대로 된 응달을 알려줄 수 없음을 알려준다.

103 Early Hints

주로 Link 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트가 사전 로딩을 시작할 수 있도록 한다.

 

200 ~ 👇🏻

201 Created

요청이 성공적이었으며, 그 결과로 새로운 리소스가 생성되었습니다.
// 일반적으로 POST요청 또는 일부 PUT요청 이후에 따라온다.

202 Accepted

요청을 수신했지만, 그에 응하여 행동할 수 없다.
// 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않는다.
// 이것은 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들었다.

203 Non-Authoritative Information

돌려받은 메타 정보 세트가 origin 서버의 것과 일치하지 않지만 로컬이나 서드파티 복사본에서 모아졌음을 의미한다.
// 이러한 조건에서는 이 응답이 아니라 200 OK 응달이 반드시 우선된다.

204 No Content

요청에 대해서 보내줄 수 있는 컨텐츠가 없지만, 헤더는 의미있을 수 있다.
// 사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있다.

206 Multi-Status

여러 리소스가 여러 상태 코드인 상황이 적절한 경우에 해당되는 정보를 전달한다.

208 Multi-Status

DAV에서 사용된다. propstat 응답 속성으로 동일 컬렉션으로 바인드된 복수의 내부 멤버를 반복적으로 열거하는 것을 피하기 위해 사용된다.

226 IM Used

서버가 GET 요청에 대한 리소스의 의무를 다 했고, 응답이 하나 또는 그 이상의 인스턴스 조작이 현재 인스턴스에 적용이 되었음을 의미한다.

 

300 ~ 👇🏻

300 Multiple Choice

요청에 대해서 하나 이상의 응답이 가능하다. 사용자 에이전트 또는 사용자는 그 중에 하나를 반드시 선택해야 한다.

301 Moved Permanently

요청한 리소스의 URI가 변경되었음을 의미한다. // 새로운 URI가 응답에서 아마도 주어질 수도 있다.

302 Found

요청한 리소스의 URI가 일시적으로 변경되었음을 의미한다. 
새로 변경된 URI는 나중에 만들어질 수 있다. 클라이언트는 반드시 향후 요청도 동일한 URI로 해야한다.

303 See Other

클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때, 
서버가 클라이언트로 직접 보내는 응답이다.

304 Not Modified

캐시를 목적으로 사용된다. 클라이언트에게 응답이 수정되지 않았음을 알려주며,
클라이언트는 계속해서 응답의 캐시된 버전을 사용할 수 있다.

307 Temporary Redirect

클라이언트가 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메소드르 사용하여 요청해야할 때
서버가 클라이언트에 이 응답을 직접 보낸다.
302 Found 와 동일한 의미를 가졌으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점이 다르다. 첫 요청이 POST 라면 두번째도 POST여야 한다.

308 Permanent Redirect

리소스가 이제 HTTP 응답 헤더의 Location: 에 명시된 영구히 다른 URI에 위치하고 있음을 의미한다.
301 Moved Permanently 동일한 의미를 가졌으며, 
첫 요청이 POST라면 두번째도 POST여야 한다.

 

400 ~ ✔️( 보통 프론트엔드와 관련 )

400 Bad Request

가장 흔한 코드이며, 클라이언트가 올바르지 않은 요청을 했을 때를 의미한다.

401 Unauthorized

인증되지 않은 사용자가 인증이 필요한 리소스를 요청하는 경우에 인증이 필요함을 알려주는 코드이다.
// 로그인이 필요한 API를 비로그인 사용자가 호출했을 때 자주 사용된다.

403 Forbidden

클라이언트가 접근이 금지된 리소소를 요청했음을 의미한다. 
간혹 401 Unauthorized와 헷갈리는 부분인데, 
401은 말 그대로 인증되지 않앗음을 의미하며, 인증이 되지 않았다는 것은 백엔드에서 현재 요청한 사용자가 누구인지 알 수 없음을 의미한다. 이 때 서버는 클라이언트에게 인증하라고 말하는 것이다.
403은 백엔드에서 현재 리소스를 요청한 사용자가 누구인지간에, 인증 여부에 상관없이 해당 리소스 요청은 무조건 금지라는 것을 의미한다.

404 Not Found

요청한 리소스가 존재하지 않는다는 것을 의미한다.

405 Method Not Allowed

현재 리소스에 맞지않는 메소드를 사용했음을 의미한다.
백엔드 프레임워크의 경우 특정 컨트롤러에 해당 메소드를 사용하는 로직이 없다면 자동으로 405를 내려주기도 한다.

406 No Acceptable

서버 주도 컨텐츠 협상을 진행했음에도 불구하고 알맞은 컨텐츠 타입이 없다는 것을 의미한다.

408 Request Timeout

클라이언트와 서버의 연결은 성사되었지만, 요청이 본문이 계속 서버에 도착하지 않는 것을 의미한다.

429 Too Many Requests

클라이언트가 서버에 요청을 너무 많이 보내는 경우에 발생한다.

 

500 ~ ✔️( 보통 백엔드와 관련 )

500 Internal Server Error

백엔드 어플리케이션 내에서 알 수 없는 에러가 발생했다는 의미이다.
제대로 핸들링되지 않은 에러가 발생한 경우가 많으므로, 원인을 클라이언트에게 알려주지 않는다.

502 Bad Gateway

백엔드 어플리케이션이 돌아가지 않는 상황이다. 

503 Service Unavailable

서버가 요청을 처리할 준비가 되지 않았음을 의미한다.
"일시적인 상황"을 의미하는 코드이다

504 Gateway Timeout

408과 마찬가지로 요청에 대한 타임아웃을 의미한다. 
하지만 504 상태 코드는 클라이언트에서 보낸 요청때문에 타임아웃이 발생하는 것이 아니라
백엔드 아키텍쳐 내부에서 서버끼리 주고받는 요청에서 발생한다.

 

브라우저의 작동 원리 ( 보이는 곳 )  ✅   

 

AJAX  ✔️

AJAX: Asynchronous JavaScript and XMLHttpRequest 

JavaScript, DOM, fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법이다.

특징:  웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다는 것이다.

ex) 검색어 추천, 쇼핑몰 무한 스크롤

 

AJAX의 장점  ☑️

서버에서 완성된 HTML을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와
브라우저에서 화면의 일부만 업데이트하려 렌더링 할 수 있다.

전체를 렌더링하는 것이 아닌, 필요한 부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 어플리케이션을 개발하기 용이.

 

AJAX의 단점  ☑️

Search Engine Optimization(SEO)에 불리

HTML 뼈대만 작성되어 있고, AJAX 방식이라면 데이터가 없기 때문에 사이트의 정보를 읽어오기 어렵다.

뒤로가기 버튼 문제

AJAX는 이전 상태를 기억하지 않기 때문에 사용자가 의도한 대로 이전 상태로 동작하지 않는다.

뒤로가기 기능을 구현하기 위해서는 별도로 History API를 사용해야 한다.

 

SSR과 CSR  ✔️

SSR: Server Side Rendering

더보기

웹 페이지를 브라우저에서 렌더링하는 대신에, 서버에서 렌더링합니다. 브라우저가 서버의 URI로 GET 요청을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 전송합니다. 그리고 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링됩니다. 서버에서 웹 페이지를 브라우저로 보내기 전에, 서버에서 완전히 렌더링했기 때문에 Server Side Rendering 이라고 합니다. 웹 페이지의 내용에 데이터베이스의 데이터가 필요한 경우, 서버는 데이터베이스의 데이터를 불러온 다음 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답으로 보냅니다. 웹 페이지를 살펴보던 사용자가, 브라우저의 다른 경로로 이동할 때마다 서버는 이 작업을 다시 수행합니다.

CSR: Client Side Rendering

 

더보기

일반적으로 CSR은 SSR의 반대로 여겨집니다.
SSR이 서버 측에서 페이지를 렌더링한다면, CSR은 클라이언트에서 페이지를 렌더링합니다.
웹 개발에서 사용하는 대표적인 클라이언트는 웹 브라우저입니다.
브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보냅니다. 이때 서버는 웹 페이지와 함께 JavaScript 파일을 보냅니다.
클라이언트가 웹 페이지를 받으면,
웹 페이지와 함께 전달된 JavaScript 파일은 브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 바꿉니다.
브라우저는 데이터베이스에 저장된 데이터를 가져와서 웹 페이지에 렌더링을 해야 합니다. 이를 위해 API가 사용됩니다.
웹 페이지를 렌더링하는 데에 필요한 데이터를 API 요청으로 해소합니다.
마지막으로, 브라우저가 다른 경로로 이동하면 SSR과 다르게, 서버가 웹 페이지를 다시 보내지 않습니다.
브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링합니다. 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일입니다.

 

SSR과 CSR의 주요한 차이는 페이지가 렌더링되는 위치이다.

SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링한다.

브라우저는 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지않고, 동적으로 라우팅을 관리한다.

SSR 예시
SEO가 우선순위인 경우 / 첫 화면 렌더링이 빠르게 필요한 경우 / 사용자와 상호작용이 적은 경우

CSR 예시
SEO가 우선순위가 아닌 경우 / 풍부한 상호작용이 많다면, CSR은 빠른 라우팅으로 사용자 경험 만족도 업 
웹 앱을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험을 제공할 수 있다.

 

출처

https://programmingtilseungho.tistory.com/entry/개발-TIL-44일차-Fri-HTTP-브라우저의-작동원리-REST-API