스미스요원

일반적인 웹 서버

• 클라이언트로부터 요청이 오면 가장 앞단에서 해당 요청에 대한 처리를 수행하고 응답을 반환하는 역할

• HTTP 요청을 받아들이고 HTML, 이미지 파일, CSS 같은 정적 컨텐츠를 반환한다.

    -  정적 컨텐츠(html, png, css 등)는 직접 제공이 가능하지만 DB등을 참조해야 하는 동적 컨텐츠는 WAS의 도움이 필요하다.

• 대표적인 웹 서버 : Apache, NGINX

• 정적 컨텐츠가 아니네! 웹서버에서 간단히 처리하지 못하겠군. WAS 에게 처리를 부탁해야겠다
     → WAS가 처리해준 데이터를 받아 와서 Response에 담아 반환

• 정적 컨텐츠구나! 내가 제공해줄게 → html, png 등을 Response에 담아 반환

웹 어플리케이션 서버(WAS, Web Application Server)(앱서버)

• 동적 컨텐츠(DB조회, 비즈니스 로직 처리가 요구되는 컨텐츠)를 제공하기 위해 만들어진 서버

    -  주로 데이터베이스 서버와 함께 가동된다.

• 웹서버와 WAS의 용어 경계가 명확한 것은 아니다 : WAS가 웹서버의 기능을 포함하는 경우가 많음

• JSP, Servlet 구동 환경을 제공하며 컨테이너, 웹 컨테이너, 서블릿 컨테이너라고 불리기도 한다.

• 대표적인 WAS : Tomcat, Jeus, JBoss

    -  SpringBoot 는 Tomcat을 내장하고 있어서 별다른 WAS 설정 없이도 서버를 구동시킬 수 있다.

• 웹서버와 앱 사이의 동적인 정보를 생성하는 역할을 담당하는 미들웨어

    -  웹서버는 앱을 알지 못하고, 반대로 앱은 웹서버를 알지 못한다.

    -  WAS가 웹서버와 앱 사이에서 중간다리 역할을 해주는 것!

    -  예) Tomcat 은 웹을 통해 들어온 HTTP request를 java 언어로 변환하여 앱에 전달하고,
             앱에서 생성된 java 응답을 다시 HTTP request로 변환하여 웹서버로 전달해주는 역할을 수행한다.

WAS 만 있어도 서버 구동은 가능하잖아?

• 사실 WAS와 DB만 있으면 당장 서비스 제공이 가능하다.

    -  WAS는 정적 리소스, 어플리케이션 로직 모두 핸들링 가능하기 때문

• 실제로 API 만 제공한다면 WAS 만 구축하기도 한다.

• 하지만 이렇게 되면 WAS가 너무 많은 일을 담당하게 된다.

    -  앱 로직도 실행해야 되고, 정적 컨텐츠도 제공해줘야 되고…

    -  정작 중요한 어플리케이션 로직이 정적 리소스를 제공하느라 바빠서 속도가 느려진다면?

• 로직을 잘못 짰거나 디비에 오류가 생겨서 WAS가 죽는다면? 오류 화면 조차 확인이 불가능

• 그래서 일반적으로는 client → Web Server(정적 리소스 처리) → WAS(동적 리소스/로직 처리) → DB
    식으로 아키텍처를 구성한다. 그러면 시스템 리소스를 효율적으로 처리할 수 있음.

• 또한 웹서버를 사용하면, 웹서버가 제공해주는 다양한 기능을 활용할 수 있다.

    -  예) NGINX : 동시 접속 처리에 특화된 웹서버 이 밖에 리버스 프록시, 캐싱, 로드 밸런싱, 미디어 스트리밍 등
             유용한 여러 역할을 수행한다.

  웹서버 + WAS의 동작 프로세스

• 클라이언트가 웹 페이지로 요청을 보내면, 웹서버가 해당 요청을 받아 필요한 부분을 WAS에 요청한다.

• WAS(컨테이너)는 web.xml 을 참조하여 해당 서블릿의 작업을 담당하는 쓰레드를 생성한다.

    -  HTTPServletRequest 와 HTTPServletResponse 객체를 먼저 생성한다.

    -  그 다음 서블릿을 호출하고, 생성한 객체를 전달한다.

• 호출된 서블릿의 작업을 담당하는 쓰레드는

    -  Request 에 따라 doPost 또는 doGet 메소드를 호출해 데이터를 먼저 생성한다.

    -  그 다음 이것를 Response 객체에 담아 다시 WAS 컨테이너에 전달한다.

• WAS 컨테이너는 전달받은 Response 객체를 HTTPResponse 형태로 바꿔 웹서버에 전달하고,
    생성되었던 쓰레드를 종료한 다음 HTTPServletRequest, HTTPServletResponse 객체를 소멸시킨다.

• 프록시 서버 (캐싱)

    -  Client와 WebServer 사이에 프록시 서버가 존재할 수 있다.

    -  자주 조회되는 정보를 프록시 서버에 캐싱하면 빠르게 접근할 수 있다.

  참고자료

1. REST(Representational State Transfer) API 란 무엇인가?

REST API의 개념과 등장 배경

• 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미

• 2000년도 로이 필딩(Roy Fielding)의 박사학위 논문에서 최초로 소개된 개념.

    -  HTTP의 주요 저자 중 한 사람

    -  웹(HTTP)이 우수한 설계에 비해 제대로 사용되지 못하고 있음에 안타까워하며 웹의 장점을 최대한 살릴 수 있는
       아키텍처로 REST를 발표했다.

REST API의 구성요소

• 자원(Resource) : URI로 표현된다.

    -  해당 소프트웨어가 관리하는 모든 데이터(문서, 그림 등)

    -  자원의 표현(Representations) : 그 자원을 표시하는 이름

        ◦  예) DB의 학생 정보가 자원일 때, students를 자원의 표현으로 정한다.

    -  URL과 URI의 차이
       

        ◦  https://agentsmith.tistory.com

        ◦  Tistory 블로그 중에서도 agentsmith의 블로그에 대한 경로를 나타내고 있다.

        ◦  서버에서는 해당 라우팅에 대한 알맞은 자원을 전송해줄 것이며, 자원의 실제 위치이므로 URL이다.

        ◦  https://agentsmith.tistory.com/12

        ◦  agentsmith의 티스토리 블로그에서 12의 ID값을 가지는 자원(포스팅)을 식별하고 있다.

        ◦  https://agentsmith.tistory.com 까지는 자원의 실제 위치이기 때문에 URI임과 동시에 URL이며, /12 부분은 식별자이다.

        ◦  즉 위 링크는 URL(https://agentsmith.tistory.com)을 포함한 URI(https://agentsmith.tistory.com/12)라고 할 수 있다. 

• 행위(Verb) : HTTP METHOD(GET, POST, PUT, DELETE)

    -  데이터가 요청되어지는 시점에서 자원의 상태(정보)를 이용한 행위

    -  JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

핵심정리

• 첫번째  URI는 정보의 자원을 표현해야 한다.

• 두번째  자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

2. 지키면 좋은 간단한 규칙들

URI Rules

• URI는 정보의 자원을 표현해야 한다.

• 자원 이름은 동사보다는 명사를 사용할 것

• 컨트롤 자원을 의미하는 URI는 예외적으로 동사를 허용한다.

• http://agentsmith.tistory.com/12/duplicate

• URI description 규칙

    -  URI 마지막에  /  를 포함시키지 말 것

    -   _  (underbar) 대신  -  (dash)를 사용할 것

    -  소문자를 사용할 것

    -  행위(method)는 URL에 포함하지 말 것

    -  자원에 대한 행위는 URI가 아닌, HTTP Method로 표현할 것

• HTTP Method

    -  GET(조회), POST(생성), PUT(수정), DELETE(삭제) 등

        ◦  GET /members/delete/1 (X)

        ◦  DELETE /members/1      (O)
       -------------------------------

        ◦  GET /members/show/1  (X)

        ◦  GET /members/1           (O)

• Colllection과 Document을 활용하면 좀 더 직관적인 REST API를 설계할 수 있다.

    -  더 큰 개념으로 생각하면 쉬움. 자원에 대한 부가적인 설명을 나타내는 역할

    -  컬렉션 : sports / 도큐먼트 : soccer

        ◦  예) http:// restapi.example.com/sports/soccer

        ◦  예) http:// restapi.example.com/sports/soccer/players/13

​

HTTP Method Rules

• 하나의 자원에 대해 POST, GET, PUT, DELETE 4가지 methods는 반드시 제공할 것

• OPTIONS, HEAD, PATCH를 사용하여 완성도 높은 API를 만들자.

• HTTP status를 method의 리턴값으로 제공할 것

• 성공 응답은 2XX 로 응답한다.

• 실패 응답은 4XX 로 응답한다. (보통 잘못된 URL 접근시 볼 수 있는 에러)

• 5XX 에러는 절대 사용자에게 나타내지 마라 (보통 DB 또는 코드의 잘못으로 나타나는 에러)

3. RequestParam vs PathVariable vs RequestBody

Path Variable

<https://agentsmith.tistory.com/{id}>
<https://agentsmith.tistory.com/12>

• 개별 자원을 구분하여 요청할 때 많이 사용하는 방법

Request Param

<https://agentsmith.tistory.com/?filter=lowPrice>
<https://agentsmith.tistory.com/?startDate=2022-04-20&endDate=2022-04-25>
<https://agentsmith.tistory.com/?page=3>

• 주로 필터링 또는 페이징을 이용해 자원을 요청할 때 많이 사용하는 방법

    -  필터링  낮은 가격 순으로 보기 / 2022-04-20~2022-04-25 만 보기

    -  페이징  데이터가 너무 많아 한 페이지에 한번에 표시하기 어려운 경우

Request Body

{
   "id": 1,
   "name": "홍길동",
   "team": { "id": 1 },
   "email": "gildong@naver.com",
   "position": "intern",
   "createdAt": "2022-04-22",
   "updatedAt": "2022-04-22"
}

• 새로운 자원을 생성하거나(POST), 자원의 정보를 한번에 수정하고 싶을 때(PUT) 주로 사용하는 방법

• JSON 형식의 데이터를 RequestBody에 담아 보낸다.

4. REST API 설계 방식 엿보기

네이버 오픈 API

카카오 오픈 API

구글 오픈 API

5. 참고자료