나를 위한 개발일지

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

RESTful API ?

: 웹 기반 시스템에서 자원(데이터나 서비스)을 명시하고 해당 자원에 접근하기 위한 규약을 제공하는 아키텍처 패턴이다. RESTful API는 "REST" (Representational State Transfer)의 원칙에 따라 설계되며, 웹의 장점을 최대한 활용할 수 있도록 특정 원칙을 따른다.

RESTful API의 핵심 원칙 ?

1. Stateless (무상태성): 각 요청은 서버에서 클라이언트의 상태 정보를 저장하지 않아야 한다. 필요한 정보는 요청 내에 포함되어야 하며, 서버는 각 요청을 완전히 분리된 것으로 처리해야 한다.
2. Client-Server (클라이언트-서버 구조): 클라이언트와 서버는 각각 분리되어 있어야 한다. 이렇게 함으로써 각각을 독립적으로 발전시킬 수 있다.
3. Cacheable (캐시 가능): 응답은 캐시 가능하거나 캐시 불가능하다는 정보를 포함해야 한다. 캐시된 응답은, 클라이언트에 의해 재사용될 수 있어야 한다.
4. Uniform Interface (일관된 인터페이스): REST의 가장 중요한 원칙 중 하나로, URL과 HTTP 메소드(GET, POST, PUT, DELETE 등)를 사용하여 리소스에 접근하고 작업을 수행한다.
5. Layered System (계층화 시스템): 클라이언트는 중간 계층(예: 로드 밸런서)의 존재 여부를 알 수 없어야 한다. 중간 계층은 앱의 확장성을 향상시키는 데 도움을 준다.
6. Code on Demand (optional): 필요한 경우 서버는 코드를 클라이언트에게 전송할 수 있다. 이는 일반적으로 JavaScript를 통해 구현된다.

HTTP 메소드는 RESTful API에서 매우 중요한 부분을 차지하며, 각 메소드는 다음과 같은 의미와 기준을 가지고 있다.

1. GET:
   • 목적: 특정 리소스를 조회
   • 비고: GET 요청은 일반적으로 데이터를 변경시키지 않아야 한다.
2. POST:
   • 목적: 새로운 리소스를 생성
   • 비고: POST 요청은 서버에 새로운 데이터를 제공하여 리소스를 생성하는 데 사용된다.
3. PUT:
   • 목적: 특정 리소스를 수정하거나 덮어쓰기
   • 비고: 만약 지정된 리소스가 존재하지 않으면 새로운 리소스를 생성할 수 있다. 하지만 이는 서버 구현에 따라 다를 수 있다.
4. PATCH:
   • 목적: 리소스의 일부분만을 수정
   • 비고: PUT 메소드와 달리, PATCH는 리소스의 일부 데이터만 변경하는 데 사용된다.
5. DELETE:
   • 목적: 특정 리소스를 삭제
   • 비고: 해당 리소스를 서버에서 제거합니다.
6. HEAD:
   • 목적: 리소스의 헤더만을 가져오기
   • 비고: GET과 비슷하지만, 응답 본문(body) 없이 헤더 정보만 반환한다.
7. OPTIONS:
   • 목적: 대상 리소스에 대한 통신을 위해 사용할 수 있는 메소드를 설명하는 응답을 반환
   • 비고: 주로 CORS(Cross-Origin Resource Sharing) 환경에서 사용된다.

REST 외에도 여러 가지 다른 통신 및 서비스 아키텍처 스타일이 있다. 예를 들면 다음과 같다.

1. WebSocket
   • 단일 TCP 연결을 통해 실시간 양방향 통신을 가능하게 하는 프로토콜이다.
   • 주로 실시간 애플리케이션(채팅, 온라인 게임 등)에서 사용된다.
2. Server-sent Events (SSE)
   • 서버에서 클라이언트로 단방향 실시간 데이터를 스트리밍하는 기술이다.
   • 주로 실시간 알림이나 라이브 피드 업데이트에 사용된다.

HTTP 메소드들은 리소스에 대한 다양한 작업을 수행할 수 있게 해주며, RESTful API는 이러한 메소드를 활용하여 표준적이고 일관된 방법으로 리소스를 처리할 수 있도록 한다.

RESTful API는 많은 웹 애플리케이션에서 널리 사용되지만, 특정 상황과 요구 사항에 따라 다른 대안들이 더 적합할 수 있다.

웹페이지가 브라우저에 렌더링되는 과정

파싱과 렌더링?

파싱(parsing)

:  프로그래밍 언어의 문법에 맞게 작성된 텍스트 문서를 읽고, 실행하기 위해 텍스트의 문자열을 분해하고 구조를 생성하는 일련의 과정

렌더링(rendering)

:  HTML, CSS, JS로 작성된 문서를 파싱하여 브라우저에 사용자가 눈으로 볼 수 있도록 시각적으로 출력하는 것

브라우저의 렌더링 과정은 요청 및 응답, HTML과 CSS 파싱, 렌더 트리 생성, 레이아웃, 페인트, 그리고 JavaScript의 실행과 같은 여러 단계로 나뉜다.

요청 및 응답

브라우저는 웹 서버에 페이지 요청을 시작하고, 서버는 HTML, CSS, JS, 이미지 등의 자원을 반환한다.

HTML, CSS 파싱 -> DOM, CSSOM 생성

반환된 HTML은 파싱되어 DOM 트리로 변환된다. DOM은 웹 페이지의 구조적 표현이다.

반환된 CSS도 파싱되어 CSSOM 트리로 변환된다. 이 트리는 스타일 정보를 포함한다.

렌더 트리 생성

DOM과 CSSOM 트리는 합쳐져 실제 화면에 표시될 요소와 스타일 정보를 포함하는 렌더 트리를 생성한다.

레이아웃

렌더 트리를 바탕으로 브라우저는 각 요소의 크기와 위치를 결정합니다. 이 단계에서는 요소의 크기와 화면에서의 위치가 계산된다.

페인트

렌더 트리와 레이아웃 정보를 활용해 실제 픽셀로 변환되어 화면에 그려진다.

JavaScript

JavaScript는 파싱되고 실행되며, 필요에 따라 DOM을 조작하거나 스타일 변경 등의 작업을 수행한다.