이력서스터디 - 데일리과제
230327
찌우닝
2023. 3. 27. 12:43
📌웹페이지가 브라우저에 랜더링되는 과정을 설명해주세요.
- 렌더링이란?
- 서버로부터 HTML, CSS, JavaScript 등 작성한 파일을 받아 브라우저에 뿌려주는 것.
- 파싱 (Parsing)
- 프로그래밍 언어의 문법에 맞게 작성된 텍스트 문서를 읽어 들여 실행하기 위해 텍스트 문서의 문자열을 토큰으로 분해하고, 토근에 문법적 의미와 구조를 반영하여 트리 구조의 자료구조인 파스 트리를 생성하는 일련의 과정.
- 쉽게 말해, 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것
- 파싱 결과는 문서 구조를 나타내는 노드 트리인데 파싱 트리(parse tree) 또는 문법 트리(syntax tree)라고 부름.
- 렌더링 과정
1. 서버로부터 넘겨받은 HTML, CSS 파일 다운
2. <Parsing> DOM / CSSOM 생성
: 브라우저의 렌더링 엔진은 서버로부터 응답된 HTML 문서를 파싱해 DOM을, CSS 문서를 파싱해 CSSOM을 생성하고 이들을 결합하여 렌더 트리를 생성
3. Render tree 생성
: DOM Tree + CSSOM Tree, 렌더링에 필요한 노드만 선택해 페이지를 렌더링하는데 사용
4. <Layout> Render tree 배치
: 렌더 트리를 기반으로 HTML 요소의 레이아웃(위치와 크기)를 계산한다.
%, vh, vw 등 상대적인 위치나 크기의 속성은 실제 화면에 그려지는 px 단위로 계산되어 변환된다.
5. <Paint> Render tree 그리기
: 레이아웃 단계에서 계산이 완료된 요소들(px)을 실제로 화면에 그리는 단계.
💡참고
📌브라우저의 기본 구조
- 사용자 인터페이스
- 주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분
- 브라우저 엔진
- 사용자 인터페이스와 렌더링 엔진 사이 동작을 제어
- 렌더링 엔진
- 요청한 콘텐츠를 표시 (ex, HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시)
- 통신
- HTTP 요청과 같은 네트워크 호출에 사용(이것은 플랫폼 독립적인 인터페이스이고 각 플랫폼 하부에서 실행됨)
- UI 백엔드
- 콤보 박스와 창 같은 기본적인 장치를 그림. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서, OS 사용자 인터페이스 체계를 사용
- 자바스크립트 해석기
- 자바스크립트 코드를 해석하고 실행
- 자료 저장소
- 자료를 저장하는 계층. 쿠키를 저장하는 것과 같이 모든 종류의 자원을 하드 디스크에 저장할 필요가 있다. HTML5 명세에는 브라우저가 지원하는 '웹 데이터 베이스'가 정의되어 있음
*여기서 렌더링 엔진이 요청받은 내용을 브라우저 화면에 표시하는 일을 수행*
📌Restful API에 대해 설명해주세요. GET,POST 외에 알고있는 메소드와 그 기준을 설명해주세요. RESTful API 가 아닌 것들은 어떤게 있나요?
- Restful API
- HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스.
- 'REST API'를 제공하는 웹 서비스를 'RESTful'하다고 할 수 있다.
- REST의 설계 규칙을 잘 지켜서 설계된 API. 즉, REST의 원리를 잘 따르는 시스템
- RESTful API 개발 원칙
- 자원을 식별할 수 있어야 한다.
- URL만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다. 자원을 제어하기 위해서 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미.
- Server가 제공하는 정보는 JSON이나 XML형태로 HTTP body에 포함되어 전송시킨다.
- 행위는 명시적이어야 한다.
- REST는 아키텍처 혹은 방법론과 비슷하다. 따라서 이런 방식을 사용해야 한다고 강제적이지 않아 기존의 웹 서비스 처럼 GET을 이용해서 UPDATE와 DELETE를 해도 된다. 다만 REST 아키텍처에는 부합하지 않으므로 REST를 따른다고 할 수는 없다.
- 자기 서술적이어야 한다.
- 데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 애플리케이션을 실행해야 하는지를 알 수 있어야 한다.
- 즉, 데이터 처리를 위한 정보를 얻기 위해서 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다.
- HATEOAS (Hypermedia as the Engine of Application State)
- 클라이언트 요청에 대해 응답을 할 때 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.
- REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어 줄 것이 필요하다.
- 이때 사용되는 것이 바로 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼링크를 제공한다.
- 클라이언트는 이 하이퍼링크를 통해서 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리할 수 있게 한다.
- 자원을 식별할 수 있어야 한다.
- RESTful API가 아닌 것
- CRUD 기능을 모두 POST로만 처리하는 API
- route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)
- REST란?
- "REpresentaionat State Transfer"의 약자로, 자원을 이름(자원의 표현)으로 구분해 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미.
- 즉, 자원(resource)의 표현(representaion)에 의한 상태 전달
- 자원 : 해당 소프트웨어가 관리하는 모든 것 (문서, 그림, 데이터, 해당 소프트웨어 자체 등)
- 표현 : 그 자원을 표현하기 위한 이름
- 상태 전달 : 데이터가 요청되는 시점에 자원의 상태를 전달한다. (JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적)
- REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다. 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나.
- 어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI(Resource)로 GET, POST 등의 방식(Method)을 사용하여 요청으 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현된다.
- REST의 구성 요소
- 자원(Resource) - URI
- 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재함
- 자원을 구별하는 ID는 '/exgroups/:exgroup_id'와 같은 HTTP URI이다.
- Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청함
- 행위(Verb) - Method
- HTTP 프로토콜의 Method를 사용함
- HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE의 Method를 제공함 (CRUD)
- Method
- GET : 정보 요청, URI가 가진 정보를 검색하기 위해 서버에 요청. (Read)
- POST : 정보 입력, 클라이언트에서 서버로 전달하려는 정보를 보냄. (Create)
- PUT : 정보 업데이트, 주로 내용을 갱신하기 위해 사용(데이터 전체를 바꿀 때). (Update)
- PATCH : 정보 업데이트, 주로 내용을 갱신하기 위해 사용(데이터 일부만 바꿀 때). (Update)
- DELETE : 정보 삭제. (안전성 문제로 대부분 서버에서 비활성화 함)
- 표현(Representation of Resource)
- Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있음.
- JSON, XML을 통해 데이터를 주고 받는 것이 일반적임.
- 자원(Resource) - URI
- REST 특징
- Server-Client 구조
- Stateless (무상태)
- Cacheable (캐시 처리 기능)
- Layered System (계층 구조)
- Uniform Interface (인터페이스 일관성)
- Self-Descriptiveness (자체 표현)
- REST API란?
- REST의 특징을 기반으로 서비스 API를 구현한 것
- 최근 openAPI, 마이크로 서비스 등을 제공하는 기업 대부분은 REST API 제공
- REST API의 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 것.
- REST API 설계 시 가장 중요한 항목
- URI는 정보의 자원을 표현해야 한다.
- 자원에 대한 행위는 HTTP Method로 표현한다.
- 행위(Method)는 URI에 포함하지 않는다.
- REST API 설계 규칙
- URI는 명사를 사용한다. (리소스명은 동사가 아닌 명사를 사용해야함)
- 슬래시(/)로 계층 관계를 표현한다.
- URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
- 밑줄(_)을 사용하지 않고, 하이픈(-)을 사용한다.
- URI는 소문자로만 구성한다.
- HTTP 응답 상태 코드 사용
- 파일확장자는 URI에 포함하지 않는다.
- URI와 URL의 차이점
- URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미
- URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로 URI는 URL을 포함.
- URI가 URL보다 포괄적인 범위라고 할 수 있음.