뚝딱뚝딱

REST : 웹(HTTP)의 장점을 활용한 아키텍쳐

1. REST (REpresentational State Transfer) 기본

• REST의 요소

• method

** idempotent : 한 번 수행하냐, 여러 번 수행했을 때 결과가 같나?

• Resource
  ✔ http://myweb/users와 같은 URI
  ✔ 모든 것을 Resource (명사)로 표현하고, 세부 Resource에는 id를 붙임
  
  
• Message
  ✔ 메시지 포맷이 존재
  : JSON, XML 과 같은 형태가 있음 (최근에는 JSON 을 씀)

HTTP POST, http://myweb/users/
{
	"users" : {
		"name" : "terry"
	}
}

• REST 특징

• Uniform Interface (일관된 인터페이스)
  
  • HTTP 표준을 기반으로 하며, 특정 언어나 기술에 종속되지 않음.
  • 예를 들어, REST API가 HTTP와 JSON을 사용하여 정의되었다면, 어떤 플랫폼이든 해당 API에 접근 가능.
• Self-Descriptive Messages (자기 서술적 메시지)
  
  • API 메시지 자체만으로도 그 의미를 이해할 수 있도록 설계해야 함.
  • 메시지를 보고도 어떤 리소스에 어떤 동작을 수행하는지 직관적으로 이해할 수 있어야 함.
• HATEOAS (Hypermedia As The Engine Of Application State)
  
  • 응답에는 현재의 상태를 나타내는 하이퍼링크가 포함되어야 함.
  • 클라이언트는 이 링크를 통해 다음에 수행 가능한 작업을 이해하고 진행할 수 있음.
• Statelessness (무상태성)
  
  • 각각의 요청은 독립적이며, 서버는 클라이언트의 상태를 저장하지 않음.
  • 이로써 서버는 간단해지고, 확장성이 높아짐.
• Resource 지향 아키텍처 (ROA)
  
  • 자원(리소스)을 중심으로 하는 아키텍처
  • 각 리소스는 고유한 URI(Uniform Resource Identifier)를 가지며, 명사 형태로 정의됨.
• Client-Server Architecture (클라이언트-서버 아키텍처)
  
  • 시스템을 클라이언트와 서버로 분리함으로써 각각의 역할을 명확하게.
• Cache Ability (캐시 사용 가능)
  
  • 응답은 캐싱될 수 있어서, 동일한 요청에 대한 반복적인 처리를 최소화
• Layered System (계층화 구조)
  
  • 시스템은 계층화될 수 있어서, 각 계층은 독립적으로 구현
  
  
• Code On Demand (선택적 코드 전송)
  
  • 서버로부터 클라이언트가 실행 가능한 코드를 전송할 수 있습니다. 이는 선택 사항이며, 일반적으로는 사용되지 않음
  
  

=> REST는 자원을 중심으로 하며, 간단하고 일관된 인터페이스를 통해 클라이언트와 서버 간의 통신을 단순화하고 효율적으로 만들기 위한 웹 아키텍처

***참고
https://gyoogle.dev/blog/web-knowledge/REST%20API.html

우리가 주소창에 주소를 입력하고 해당 페이지로 이동하여 화면에 보여지는 과정은 어떻게 이루어질까?

• 주소창에 url을 입력하고 enter를 누르면, 서버에 요청이 전송된다.
• 해당 페이지에 존재하는 여러 자원들 (text, image 등등)이 보내진다.
• 이제 브라우저는 해당 자원이 담긴 html과 스타일이 담긴 css를 W3C 명세에 따라 해석할 것이다.
  => 이 역할을 하는 것이 "렌더링 엔진"
• 렌더링 엔진은 우선 html 파싱 과정을 시작한다. html 파서가 문서에 존재하는 어휘와 구문을 분석하면서 DOM 트리를 구축한다.
• 다음엔 css 파싱 과정을 시작한다. css 파서가 모든 css 정보를 스타일 구조체로 생성한다.
• 이 2가지를 연결시켜 렌터 트리를 만든다.
  => 렌더링 엔진을 통해 (DOM 트리 + 스타일 구조체 = 렌더 트리)를 만든다!!
• 즉 렌더 트리를 통해 문서가 시각적 요소를 포함한 형태로 구성된 상태가 된다.
• 화면에 배치를 시작하고, UI 백엔드가 노드를 돌며 형상을 그린다.
• 이때 빠른 브라우저 화면 표시를 위해 '배치와 그리는 과정'은 페이지 정보를 모두 받고 한꺼번에 진행되지 않는다.
• 자원을 전송 받으면, 기다리는 동시에 일부분 먼저 진행하고 화면에 표시한다.
  => 우리가 웹 페이지에 접속할 때 한꺼번에 뜨지 않고 점점 화면에 나오는 것이 이 때문이다!!

***아래는 각 단계에서의 세부 동작에 관한 내용이다

브라우저 주요 기능

브라우저는 html과 css 명세에 따라 html 파일을 해석해서 표시한다.

이 "명세"는 웹 표준화 기구인 W3C(world wide web consortium)에서 정해진다.

예전 브라우저들은 일부만 명세에 따라 구현하고 독자적 방법으로 확장했음 -> 결국 심각한 호환성 문제가 발생하고, 요즘은 대부분 모두 표준 명세를 따름

브라우저가 가진 인터페이스는 보통 비슷비슷한 요소들이 존재한다.

** 브라우저가 가진 인터페이스는 아래와 같은 것들

시간이 지나면서, 사용자에게 필요한 서비스들로 서로 모방하며 갖춰지게 된 것

• URI 입력하는 주소 표시 줄
• 이전 버튼, 다음 버튼
• 북마크(즐겨찾기)
• 새로 고침 버튼
• 홈버튼...등등

브라우저 기본 구조

• 사용자 인터페이스
  주소 표시줄, 이전/다음 버튼, 북마크 등 사용자가 활용하는 서비스들 (요청한 페이지를 보여주는 창을 제외한 나머지 부분)
• 브라우저 엔진
  사용자 인터페이스와 렌더링 엔진 사이의 동작 제어
• 렌더링 엔진
  요청한 콘텐츠 표시 (html 요청이 들어오면? -> html, css 파싱해서 화면에 표시)
• 통신
  http 요청과 같은 네트워크 호출에 사용 (플랫폼의 독립적인 인터페이스로 구성되어 있음)
• UI 백엔드
  플랫폼에서 명시하지 않은 일반적 인터페이스. 콤보 박스 창 같은 기본적 장치를 그림
• 자바스트립트 해석기
  자바스트립트 코드를 해석하고 실행
• 자료 저장소
  쿠키 등 모든 종류의 자원을 하드 디스크에 저장하는 계층

렌더링이란?

렌더링 엔진은 요청받은 내용을 브라우저 화면에 표시해준다.

기본적으로 html, xml 문서와 이미지를 표시할 수 있다.

추가로 플러그인이나 브라우저 확장 기능으로 pdf 등 다른 유형도 표시가 가능하다.

(확장이 필요한 유형은 바로 뜨지 않고 팝업으로 확장 여부를 묻는 것을 볼 수 있다)

렌더링 엔진 종류

• 크롬, 사파리 : 웹킷(Webkit) 엔진 사용
• 파이어폭스 : 게코(Gecko) 엔진 사용

웹킷(Webkit) : 최초 리눅스 플랫폼에 동작하기 위한 오픈소스 엔진

렌더링 동작 과정

DOM : Document Object Model (문서 객체 모델)
DOM은 웹 브라우저가 html 페이지를 인식하는 방식

파싱

문서 파싱은, 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것이다.

문서를 가지고 어휘분석과 구문 분석 과정을 거쳐 파싱 트리를 구축한다.

*** Gyoogle.com 글을 참고하였습니다.