MVC 폼 처리

@GetMapping
부트 스트랩에서 가져올 수 있다.

• 서비스를 컨트롤러가 사용한다.
  컨트롤러는 어플리케이션의 입구.
  외부, 클라이언트(브라우저)에서 데이터를 받아온다.(HTTP)
  컨트롤러는 HTTP에 대한 것들을 핸들링한다.
  실제 도메인 로직은 서비스와 엔터티에서 다룬다.

Web Application Context

• Application Context를 상속.
• Servlet Context에 접근할 수 있는 기능이 추가된 Application Context
  서블릿 컨텍스트는 Servlet Container에 의해 만들어짐.
• 여러 서블릿의 공유가 가능한 정보를 담고 있는 일종의 객체.
  여러 서블릿에서 접근해서 공용 자원처럼 사용됨.
• 서블릿 컨테이너가 만들어지며 서블릿 컨텍스트가 만들어지고, 개별 서블릿 컨텍스트가 만들어질때 전체 필요한 정보를 담게 됨.
  디스패쳐 서블릿도 일종의 서블릿. 생성할 때 Web Application Context를 전달함.
• 서블릿 컨텍스트는 즉 여러 서블릿에서 접근이 가능하니까 여러 디스패쳐 서블릿에서도 접근 가능함.
  디스패쳐 서블릿과 웹 어플리케이션 컨텍스트는 여러개가 만들어짐.
  여러 디스패쳐 서블릿이 만들어지고, 개별적으로 웹 어플리케이션 컨텍스트가 만들어짐.

• 서블릿이 서블릿 컨텍스트에 접근할 수 있듯이, 모든 어플리케이션 컨텍스트가 접근 가능한 Root Application Context가 필요함.
• 루트 어플리케이션 컨텍스트는 언제 만들어지냐, 바로 서블릿 컨텍스트가 만들어질 때 루트 어플 컨텍스트가 만들어지고 setAttribute()를 통해 서블릿 컨텍스트에 들어가짐.
  디스패쳐 서블릿은 서블릿 컨텍스트에 접근하고 거기서 웹 어플 컨텍스트를 갖고와 디스패쳐 서블릿에 만들어진 어플 컨텍스트랑 부모자식 관계를 만들어줌.

Root Application Context의 생성

• 두가지 방법.
  • web.xml,
  • 자바 코드 기반.
• 스프링은 ServletContextListener을 구현한 ContextLoaderListener을 제공함.
  서블릿 컨텍스트 리스너는 서블릿 컨텍스트가 만들어질 때 같이 만들어지고 호출돼서 특정한 서블릿 컨텍스트 상태가 변경될 때 호출되어지는 일종의 Listener.
• ContextLoaderListener를 통해 웹 어플리케이션 전체에서 사용 가능한 웹 어플리케이션 컨텍스트 생성. 이것을 편의상 Root Application Context라고 함.
  그냥 어플리케이션 컨텍스트의 차이점은 서블릿 컨텍스트에 접근할 수 있느냐, 없느냐.
  파라미터에 대한 정의가 컨텍스트 로더 리스너에 되어있음.

웹 환경에서 스프링 어플리케이션이 동작하는 방식

• 서블릿 컨테이너 안에 (동작하는)웹 어플리케이션이 들어가 있음. 이 안에 서블릿과 서블릿 컨텍스트가 존재한다.
• 웹 어플리케이션에서 웹 어플리케이션 컨텍스트를 생성하고 여기에서 디스패쳐 서블릿이 필요시 웹 어플리케이션 컨텍스트에 등록되어져 있는 빈들을 가져옴.
  웹 어플 컨텍스트에 등록되어져 있는 컨트롤러가 있다면 디스패쳐 서블릿이 컨트롤러에게 요청을 위임함. Bean 오브젝트 생성.
• ApplicationContext.xml에는 Bean을 생성하기 위한 메타데이터가 있다.

• 프레젠테이션 계층에서는 사용자의 요청에 대해 처리하는 부분이 위치. 외부와 상호작용하는 기능이 많이 있다.

• 서비스 계층은 실제 비즈니스 로직을 담당하게 됨.

• 데이터 액세스 계층에서는 DAO나 레포지토리를 이용해서 DB에 접근함.

  • 예전에 DAO를 많이 썼다면 지금은 레포지토리를 많이 사용함.

• 클라이언트의 요청을 디스패쳐 서블릿이 받음. 디스패쳐 서블릿은 컨트롤러에 위임.

• 컨트롤러는 서비스를 검색, 호출해서 요청을 처리하고, 서비스는 데이터를 저장하거나 데이터를 불러와 컨트롤러에 전달함.

• 디스패쳐 서블릿은 JSP view를 만들고, view가 HTML을 만들고 바디에 실어서 브라우저로 보내면 브라우저는 그것을 랜더링 해 출력함.

• Spring MVC 모듈이 프레젠테이션 계층에 해당.
  전체에 spring 컨테이너 IOC기술 적용.

• 디스패쳐 서블릿은 여러개가 만들어질 수 있음.
  컨트롤러는 해당 디스패쳐 서블릿에 매핑되어 있음.
• 디스패쳐 서블릿이 사용하는 컨트롤러는 디스패쳐 서블릿을 만들 때 전달된 웹 어플리케이션 컨텍스트, 즉 서블릿 어플리케이션 컨텍스트라고 부르는 IOC컨테이너가 생김.
  여기에 컨트롤러를 등록하고 디스패쳐 서블릿이 필요한 빈들이 다 등록됨.
  여러개가 만들어짐.
• 서비스와 DAO영역은 여러 서블릿에서 공통적으로 사용되며, root applicationContext라 부를 수 있음.
  하나만 만들어진다.

• 서블릿을 하나로 만들어버릴 수 있다.
  하나의 컨테이너에 모든 빈들을 등록.

모놀릭 아키텍쳐

• 하나의 어플리케이션에 모든 빈들을 등록해서 사용.
• 모든 기능이 한 어플에 있고 수직확장이 가능하다.
  사용자가 많아지고, 트래픽이 커지면 하드를 업그레이드(램 업글. cpu 증가. 디스크 확장 등.).
  가용성을 높이기 위해 여러 대를 사용할 수 있음. 로드 밸런서 삽입.
• 한대의 서버가 여러개 처리, 수평적으로 확장될 수 있지만, 실질적으로 한 곳에서 기능이 처리가 됨.

마이크로 서비스 아키텍쳐

• 최근의 트렌드.
• 로직의 서비스를 여러 어플에 분산, 나눠서 처리하는 방법이 발달.
• 하나의 서버가 하나의 서비스나 기능만 담당하며, 소스 코드 레포지토리, DB 기술 등이 분리된다.
• 서비스들을 텍부터, DB기술, 텍 스택, 운영, 소프트웨어 라이프사이클 까지 분리.
• 서블릿 컨텍스트를 하나만 만듦.
• 한계 : 큰 프로젝트를 하면 service, controller가 너무 많아지고, root aplicationContext의 크기도 너무 커진다.

REST(ful) API

REST : Representational State Transfer

월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식.

• 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었고 필딩은 HTTP의 주요 저자 중 한 사람.
• 엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음.
• '네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법
• 간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 간단한 인터페이스 말함.

API

• protocols이나 subroutine. 어플리케이션을 만들기 위한 하나의 subroutine definitions. 다양한 소프트웨어 컴포넌트가 커뮤니케이션하기 위해서 정의된 방법들.
• 어플리케이션을 만들 때 여기에 다양한 기능들이 있는데, 다른 소프트웨어 컴포넌트들과 커뮤니케이션하기 위한 방법들.
  커뮤니케이션하기 위해선 규약이 필요하한데, 이것을 REST로 정의한 것이 REST API.
• REST아키텍쳐 스타일을 따르는 API가 REST API.
  웹 상에서 리소스를 전달하기 위한 것.
  리소스를 전달할 때 SOAP해서 전달하면 HTTP를 사용한거지만, 아키텍쳐 스타일을 따르면 REST.

REST 아키텍쳐 스타일

• 클라이언트 - 서버 (client-server)

  • 사용자 인터페이스에 대한 관심을 데이터 저장에 대한 관심으로부터 분리함으로써 클라이언트의 이식성과 서버의 규모확정성을 개선.

• 스테이트리스 (stateless)

  • 클라이언트 서버의 통신에 상태가 없다. 모든 요청에는 필요한 모든 정보를 담고 있어 가시성이 좋고 요청 실패시 복원이 쉽기 때문에 신뢰성이 좋음. 상태를 저장할 필요가 없어 규모확장성이 개선됨.

• 캐시 (cache)

  • 캐시가 가능해야 함. HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능.

• 균일한 인터페이스 (uniform interface)

  • URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍쳐 스타일을 말함.

  

• 상속도 모델.

• 레벨이 3이면 가장 REST 아키텍쳐 스타일에 근접하게 API를 만들었다.
  레벨 0은 REST API가 아니다. 그냥 HTTP이다.

  • 레벨 0 : 가장 하위의 레벨. HTTP로 리소스를 전달했다는 것에 의의.
    REST는 아니다.
    SOAP 기반의 프로토콜. 단 하나의 엔드 포인트만 존재하며 URL도 하나. 요청을 xml로 정의함. 포스트로 호출. 서버가 xml을 전달받고 그 응답을 xml로 줌. 하나의 URL에 xml로 왔다갔다 한다.
    이것은 REST API가 아니다. REST API는 URL로 균일한 인터페이스를 제공해야하기 때문.

    • 일종의 remote procedure call(리모트 프로시저 호출). 외부에 있는 메서드를 호출한다.

  • 레벨 1 : Resources 추가.
    리소스 단위로 여러 개의 엔드포인트 추가. 그러한 엔드포인트는 리소스 중심으로 설계됨.

  • Representation data : 리소스가 어떻게 표현되어야 하는 것을 나타낸 것.
    Representations : 하나의 information이 다양한 방식으로 표출할 수 있다는 것을 의미. 하나의 리소스에 대해 다양한 형식으로 표현할 수 있음.
    어떠한 리소스의 특정 시점의 상태를 반영하고 있는 정보이고 representation data와 representation metadata로 구성.

    

  • 레벨 2 : HTTP 메서드 도입. (Verbs는 동사인데, 메서드를 의미.)
    적절한 HTTP메서드를 사용함.

  • 레벨 3 :
    HATEOAS
    Hypermedia as the Engine of Application State (hey-dee-us)
    API에서 resource에 대한 응답을 받았는데, 리소스가 모든 리소스에 대한 연결성을 가져야함.

    • Hypermedia : 초월된, 연결된. 모든 것이 연결되어있다는 의미.

• 계층화된 시스템 (layered system)

  • REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.

API 설계

1. URI는 정보의 자원을 표현해야 한다. (리소스 명은 동사보다는 명사를 사용.)
   GET /members/delete/1 > 이런식은 X
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현.

DELETE /members/1        O
GET /members/show/1      X
GET /members/1           O
POST /task/1/run         O

3. 슬래시 구분자/는 계층 관계를 나타내는데 사용.
4. URI 마지막 문자로 슬래시/를 포함하지 않는다.
5. 하이픈 -은 URI 가독성을 높이는데 사용.
6. 액션은 맨 마지막에 붙이자. (특정한 verve를 표현할 때가 있다. 실행시키는 액션 등. 그럴 때는 맨 마지막에 붙이자.)

스프링에서 REST API 사용하기

• 에노테이션 추가
  @RequestBody : 전달받은 요청 메세지를 원하는 형태로 변환.
  @ResponseBody : 정의한 모델 클래스를 ResponseBody 형태로 변환.
  @Restontroller : 컨트롤러에 ResponseBody추가.

• RequestBody HttpEntity @ResponseBody 등으로 리턴하게 되면, HTTP 메세지 컨버터가 동작함.
  HTTP 메세지 컨버터는 반환된 HTTP 메세지로 변환시켜줌.