[기술 면접 스터디-1일차] 브라우저 렌더링 원리, RESTful API

1. 웹페이지가 브라우저에 렌더링되는 과정을 설명해주세요.

각 브라우저에는 렌더링 엔진이 존재하는데 이 렌더링 엔진이 critical rendering path 프로세스를 거치며 화면을 렌더링 합니다.

1. 사용자가 주소 표시줄에 URI 입력
2. 브라우저 엔진이 캐시에서 해당 URI의 캐싱된 데이터가 있는지 확인, 있다면 해당 자료를 렌더링 엔진에게 보내주고, 없다면 렌더링 엔진이 네트워크에 URI를 전달하여 네트워크가 해당 서버에 요청을 보내고, 응답받은 리소스를 렌더링 엔진에게 전달
3. 렌더링 엔진의 HTML파서가 HTML태그를 한줄씩 파싱하여 브라우저가 이해할 수 있는 Node 객체로 변환하고, 이 Node, 즉 DOM의 계층 구조인 DOM Tree를 형성
4. CSS파서가 CSS를 casecading rule에 따라 우선순위를 적용해 최종 계산된 스타일로 CSSOM을 생성
5. DOM과 CSSOM을 병합하여 실적적으로 브라우저에 표기될 요소들만 선별하여 Render Tree를 생성
6. 자바스크립트 코드는 자바스크립트 엔진의 인터프리터가 해석하고 실행
7. 렌더링 엔진이 구축한 Render Tree를 기반으로 UI 백엔드가 layout -> paint -> composition 과정을 거치며 최종적으로 브라우저 화면이 그려지게 됩니다.

관련 포스팅

브라우저의 구성 요소와 렌더링 과정

 

2. RESTful API에 대해 설명해주세요. GET,POST 외에 알고 있는 메소드와 그 기준을 설명해주세요. RESTful API 가 아닌 것들은 어떤 게 있나요?

- REST는 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 것 입니다. HTTP URI를 통해 자원을 명시하고 HTTP 메서드(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는 것을 의미합니다.
- RESTful API는 REST 원칙을 적용하여 서비스 API를 설계한 것을 말합니다.

GET : 요청받은 URI 정보를 검색하여 응답합니다.
POST : 요청된 자원을 생성합니다.
DELETE: 요청된 자원 삭제를 요청합니다.
PUT: 요청된 자원 전체를 수정합니다.

그밖에도
PATCH: 요청된 자원 일부를수정합니다.
OPTIONS: 웹서버에서 지원되는 메서드의 종류를 확인할 경우 사용합니다.
HEAD: GET 방식과 동일, 하지만 응답에 BODY가 존재하지 않으며, 응답코드와 HEAD 만 응답합니다.
CONNECT: 동적으로 터널모드를 교환, 프록시 기능을 요청시 사용합니다.
TRACE: 원격지 서버에 루프백 메세지를 호출하기 위해 테스트용으로 사용합니다.
등이 있지만 일반적인 어플리케이션에서는 잘 사용하지 않습니다.


RESTful API이 아닌 경우는 SOAP(Simple Object Access Protocol-XML기반), XML, JSON, GraphQL

HEAD :  클라이언트가 본문 없이 리소스에 대한 더만 검색하는 경우 사용한다. -> 일반적으로 클라이언트가 서버에 리소스가 있는 지 확인하거나 메타 데이터를 읽으려는 때만 GET 대신 사용한다.

OPTIONS : 클라이언트가 서버의 리소스에 대해 수행 가능한 동작을 알아보기 위해 사용한다. -> 일반적으로 서버는 이 리소스에 대해 사용할 수 있는 HTTP 요청 메서드를 포함하는 Allow 헤더를 반환한다. (CORS에 사용)

 

 

다른 팀원의 답변

RESTful API는 원격과 로컬간의 데이터를 주고 받을때 URI을 통해 자원을 명시하고 HTTP Method를 통해 해당 자원의 CRUD를 구분하는 방법론을 뜻합니다. RESTful API에서 사용되는 메소드는 크게 GET, POST, PUT, DELETE가 있습니다. GET은 리소스를 조회할 때, POST는 리소스를 생성할 때, PUT은 존재하고 있는 리소스를 수정할 때, DELETE는 리소스를 삭제할 때 사용됩니다. 이 외에도 OPTIONS, HEAD, PATCH 등의 메소드가 있지만, 이들은 보통 RESTful API에서는 잘 사용되지 않습니다. RESTful API가 아닌 것으로는 XML과 HTTP를 결합한 SOAP 등이 있는 것으로 알고 있습니다. 원격과 로컬간의 연동은 많은 방법론을 통해 이루어져 왔지만 HTTP 프로토콜의 리스폰스, 에러 코드 등을 그대로 재사용 할 수 있다는 점과 개발자이 보다 직관적으로 이해할 수 있다는 점에서 RESTful API가 많이 사용되는 것으로 알고 있습니다.

 

+ PATCH는 RESTful API에서 잘 사용되지 않는 이유

일관성 부족: PATCH 메서드는 리소스의 부분적인 수정을 지원합니다. 하지만 이렇게 부분적으로 수정하는 것은 API의 일관성을 해치기 쉽습니다. 서버와 클라이언트 간의 의사소통이 복잡해질 수 있고, API의 작동 방식을 이해하기 어려울 수 있습니다.

복잡성과 위험성: PATCH는 리소스의 일부만 변경할 수 있기 때문에 리소스의 구조가 복잡하거나 중첩된 경우에는 적절한 변경이 어려울 수 있습니다. 또한 사용자가 실수로 리소스를 손상시키는 위험성도 존재합니다.

보안 이슈: PATCH는 일부 데이터만 전송하므로, 보안 문제가 발생할 수 있습니다. 예를 들어, 클라이언트가 리소스의 중요한 부분만 수정하도록 설계되었지만, 악의적인 사용자가 해당 리소스를 손상시킬 수 있습니다.

기타 HTTP 메서드의 충분성: 대부분의 경우 PUT 메서드를 사용하여 리소스 전체를 교체하는 것이 충분합니다. RESTful API는 대개 리소스의 전체 수정이 필요한 경우 PUT을 사용하고, 부분적인 수정이 필요한 경우 POST를 사용하는 등 다른 HTTP 메서드를 이용하여 일관성 있는 API를 설계할 수 있습니다.

지원의 한계: 일부 서버 및 클라이언트는 PATCH 메서드를 제대로 지원하지 않을 수 있습니다. 이로 인해 호환성 문제가 발생할 수 있습니다.

따라서 대부분의 경우 PUT과 POST를 적절하게 사용하여 RESTful API를 설계하는 것이 더 일반적이고 권장되는 방법입니다.

관련 포스팅

REST API란 무엇인가?

 

 

기술 면접 후 느낀 점

- 실제로 사용한 경험을 포함하여 얘기하는 것이 좋다.

더 공부할 점

- 자바스크립트는 언제 실행 되는지 -> 리액트에서의 자바스크립트 실행 시점

- Reflow, Repaint의 개념 : 키워드 (성능, 비용)

-Reflow -> px
윈도우 창, 스타일 추가 제거, 폰트, hover
요소의 크기, 위치 변경 시 일어남
flex -> justify에서 column 등, 뷰포트상 움직임
position에서 absolute는 -> reflow를 여러번 발생x 사용시 지향

- Repaint
visivility, opacity 성능에 더 좋다.

- 링키드리스트 : 3개의 연결된 리스트를 구하고 CRUD 구현하기 등