[Interview] 면접 관련 정리6

자바 컴파일 과정

1. 개발자가 자바 소스코드(.java) 작성
2. 컴파일러가 자바 소스파일을 컴파일
3. 이때 나오는 파일은 자바 바이트 코드(.class) 파일로, 아직 컴퓨터가 읽을 수 없고, JVM이 이해할 수 있는 코드
4. 컴파일된 바이트 코드를 JVM의 클래스 로더에게 전달
5. 클래스 로더는 동적 로딩을 통해 필요한 클래스들을 로딩 및 링크하여 JVM 메모리에 올림
6. 실행 엔진(Execution Engine)은 JVM 메모리에 올라온 바이트 코드들을 명령어 단위로 하나씩 가져와서 실행.
   • 인터프리터 : 바이트 코드 명령어를 하나씩 읽어서 해석하고 실행
     • 하나하나의 실행은 빠르나, 전체적인 실행 속도가 느리다는 단점
   • JIT(Just In Time)컴파일러 : 인터프리터의 단점을 보완하기 위해 도입된 방식으로, 바이트 코드 전체를 컴파일하여 바이너리 코드로 변경하고, 이후에는 해당 바이너리 코드로 직접 실행하는 방식
     • 바이트 코드 전체가 컴파일된 바이너리 코드를 실행하는 것이기 때문에 전체적인 실행 속도는 인터프리터 방식보다 빠름.

브라우저 기본 구조

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

렌더링

렌더링 엔진은 요청 받은 내용을 브라우저 화면에 표시해준다.(기본적으로 hmtl, xml, image 표시)
추가로 플러그인이나 브라우저 확장 기능으로 pdf등 다른 유형도 표시 가능

렌더링 엔진 종류

• 크롬, 사파리 : Webkit 엔진
• 파이어폭스 : Gecko 엔진

렌더링 동작 과정

• html 문서 파싱
  • 태그를 모두 DOM 노드로 변환한다.
• css 파일과 함께 포함된 스타일 요소 파싱
• 어태치먼트가 DOM 노드와 스타일 정보를 연결해 렌더트리 생성
• 생성된 렌더 트리는 정해진 순서대로 화면에 표시되는데, UI 백엔드에서 렌더 트리의 각 노드를 가로지으며 형상을 만드는 그리기 과정이 진행.
  • 렌더링 엔진은 좀 더 빠르게 사용자에게 제공하기 위해 모든 html을 파싱할 때 까지 기다리지 않고, 배치와 그리기 과정을 시작한다.

브라우저 동작 과정

• 주소창에 URL을 입력하면 서버에 요청이 전송.
• 해당 페이지에 존재하는 여러 자원들(text, image 등)이 보내짐.
• 브라우저는 받은 html과 css를 명세에 따라 해석. -> 렌더링 엔진의 역할
• 렌더링 엔진은 html 파싱 과정을 시작하고, html 파서가 DOM 트리 구축.
• css 파서가 모든 css 정보를 스타일 구조체로 생성.
• DOM 트리와 스타일 구조체를 연결해서 렌더 트리 생성
• 화면에 배치를 시작하고, UI 백엔드가 노드를 돌며 형상을 그림
  • 이때, 빠른 표시를 위해 자원을 전송받으면, 기다리는 동시에 일부분 먼저 진행하고 화면에 표시.

REST API

API 정의

두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스

REST(Representational State Transfer)는 API 작동 방식에 대한 조건을 부과하는 SW 아키텍처.

REST

• HTTP URI를 통해 자원(Resource)을 명시.
• HTTP Method(POST, GET, PUT, DELETE, PATCH)를 통해 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미.

REST 구성 요소

1. 자원(Resource) : HTTP URI
2. 자원에 대한 행위(Verb) : HTTP Method
3. 자원에 대한 행위의 내용(Representations) : HTTP Message Payload

REST 특징

• Uniform Interface
  • HTTP 표준만 맞다면, 어떤 기술도 가능한 Interface 스타일
  • Ex) REST API 정의를 HTTP + JSON으로 하면, C, JAVA, Python, IOS 등 특정 언어나 기술에 종속받지 않고, 모든 플랫폼에서 사용 가능
• Stateless(무상태성)
  • 작업을 위한 상태 정보를 따로 저장/관리 X
  • 세션에 정보나 쿠키 정보를 별도로 저장/관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리.(덕분에 구현 단순)
• Cacheable(캐시 가능)
  • HTTP라는 기존 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용 가능.(Last-modified or E-Tag)
• Self-Descriptiveness(자체 표현 구조)
  • REST API 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어 있음.
• Client - Server 구조
  • REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로, 각각 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고, 서로간 의존성이 떨어진다.

디자인 가이드

• URI는 정보의 자원을 표현 (Resource명은 동사보다는 명사 사용)
  • EX) GET/members/delete/1 (X) - 자원을 표현하는데 중점을 둬야하며, delete 같은 행위 표현은 X
• 자원에 대한 행위는 HTTP Method로 표현
  • EX) DELETE /members/1

REST 장점

• HTTP의 인프라를 그대로 사용하기 때문에 REST API 사용을 위한 별도의 인프라 구축을 안해도 된다.
• HTTP 표준에 따르는 모든 플랫폼에서 사용 가능
• REST API 메시지만 보고도 의도하는 바 쉽게 파악 가능
• 서버와 클라이언트의 역할을 명확하게 분리

REST 단점

• 표준 자체가 존재하지 않아 정의가 필요
• HTTP Method 형태가 제한적.
• 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(Explore)

설계 예시

• URI는 동사보다는 명사, 대문자보다 소문자
  • EX) http://google.com/Running (X)
  • Ex) http://google.com/running (O)
• 마지막에 / 포함 X
  • URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하므로, 혼동을 주지 않도록 경로 마지막에는 / 사용하지 않는다.
  • Ex) http://google.com/test/ (X)
  • Ex) http://google.com/test (O)
• _대신 - 사용 (가독성)
  • Ex) http://google.com/test_blog (X)
  • Ex) http://google.com/test-blog (O)
• 파일 확장자는 URI에 포함 X
  • Accept header 사용
  • Ex) http://google.com/photo.jpg (X)
  • Ex) http://google.com/photo (O)
• 행위 포함 X
  • Ex) http://google.com/delete-post/1 (X)
  • Ex) http://google.com/post/1 (O)

RESTful

RESTful API는 HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식.

즉, REST의 원리를 따르는 시스템을 의미.
CRUD 기능을 POST로 처리하는 API 또는 URI 규칙을 올바르게 지키지 않는 API는 REST API를 사용했지만, RESTful하진 못하다.
즉, REST API의 원리를 잘 따라서 만든 API가 RESTful한 API라 할 수 있다.