[네트워크] Web Server, WAS, Rest API

서버의 여러가지 아키텍처에 대해 알아보자

Web Server

• html, css, js와 같은 정적 컨텐츠 제공
• 로드밸런싱, 리다이렉트의 역할 수행
• Apache, Nginx 등이 있음

WAS (Web Application Server)

• 동적 컨텐츠 제공
• 웹서버만으로 수행하지 못하는 DB 조회 및 다양한 로직처리 수행
• Tomcat, under tow 등이 있음

Web Server와 WAS 분리

• WAS만으로 모든걸 수행할 수 있지만, 이는 서버에 과부하를 일으킬 수 있음
• 웹서버와 WAS를 분리함으로써 서로의 책임을 나눌 수 있음
  • 정적 컨텐츠 처리는 웹서버에 할당
  • 동적 컨텐츠 처리는 WAS에 할당
  • 서버의 확장성을 높일 수 있음

동작원리

Web Server

• Apache
  • 멀티 프로세스 + 멀티 스레드
  • 1개의 자식 프로세스가 여러개의 스레드를 가지고, 하나의 스레드가 하나의 요청 처리
  • 요청이 많아질수록 프로세스와 스레드를 계속 생성해서 문맥교환이 자주 발생 -> 오버헤드 발생
• Nginx
  • 싱글 프로세스 + 멀티 스레드
  • 비동기 이벤트 방식으로 동작함
  • 여러개의 요청을 비동기적으로 처리하기때문에 고정된 숫자의 프로세스를 사용

Spring Boot에서의 흐름

• 스프링 부트 구동시 기본으로 Tomcat이 WAS의 역할을 함
• Tomcat 구동시 스레드풀이 생성되고 1 request == 1 thread로 동작함
• 서블릿 컨테이너가 서블릿을 관리하고, 하나의 스레드당 하나의 서블릿 객체가 생성됨 (싱글톤 패턴)

REST (REpresentational State Transfer)

• HTTP의 장점을 최대한 활용할 수 있는 아키텍처 스타일
• REST API 버저닝의 최고는 버저닝을 안하는것

장점

• 서버와 클라이언트의 역할을 명확하게 분리함
• 다양한 클라이언트를 하나의 REST API 서버로 지원이 가능함
• HTTP를 그대로 사용하므로, 별도의 인프라를 구축하지 않아도 됨
• HTTP를 사용하는 모든 플랫폼에서 사용 가능
• REST API가 의도하는 바를 명확하게 나타내므로 알아보기 쉬움

단점

• 표준이 존재하지 않는다

구성요소

• 자원(Resource) : HTTP URI를 통해 자원을 명시
• 행위(Verb) : HTTP Method를 통해 자원에 대한 행위를 명시
• 표현(Representation of Resource) : json, xml등을 통해 데이터를 주고 받음

특징

• Server-Client(서버-클라이언트 구조)
• Stateless(무상태) : HTTP를 사용하므로 동일하게 무상태성을 가짐
• Cacheable(캐시 처리 가능) : HTTP가 지원하는 캐시 기능 사용 가능
• Layered System(계층화) : Rest API 서버를 계층화할 수 있다 (로드밸런싱, 게이트웨이 등등)
• Uniform Interface(인터페이스 일관성) : 특정 언어에 종속되지 않고 HTTP URI만 충족시키면 됨
• Code-On-Demand(optional) : 서버로부터 스크립트를 받아 실행함 (필수X)

URI 설계 규칙

• 소문자를 사용한다
• 동사보다 명사를 사용한다
  • 자원에 대한 행위는 HTTP Method로 정의한다
• 자원에는 복수 명사를 사용한다
• 마지막 문자로 슬래시(/)를 포함하지 않는다
• 가독성을 높여야 한다면 언더바(_)를 사용하지 않고 하이픈(-)을 사용한다
• 파일확장자(.포함된것)는 제외한다
  • HTTP 헤더를 사용한다

URI vs URL

• URI (Uniform Resource Identifier)
  • 웹에서 사용하는 논리적/물리적 리소스를 구별하는 식별자
• URL (Uniform Resource Locator)
  • 웹에서 사용하는 리소스의 위치를 나타내는 URI의 서브셋 (웹주소)
  • 리소스의 위치를 정확하게 표현해야함!