[SPRING]Web Application

[1] Web Application

1.1. 엔터프라이즈 애플리케이션 (Enterprise Application) 개발의 복잡함

• 비즈니스 로직의 복잡함
• 수 많은 사용자와 데이터를 대응하기 위한 기술적인 제약조건과 요구사항
• 복잡함을 다루기 위한 전략
  • 프레임워크
  • 스프링 프레임워크
  • 객체지향 설계
• DI, AOP

1.2. 웹 애플리케이션 (Web application)

• 인터넷을 통해 웹 브라우저에서 이용할 수 있는 응용 소프트웨어
• SNS, 웹 메일, 전자상거래, 인터넷 게시판, 블로그 등 다양한 기능을 제공

1.3. 웹 애플리케이션의 동작

• 웹 브라우저는 URL을 기반으로 보고 싶은 컨텐트를 HTTP 요청함
  • HTTP 메소드 (GET, POST 등)와 콘텐트 주소 (URL)
  • 요청 헤더
  • 요청 본문 (쿼리 스트링, 폼 데이터 등)
• 웹 애플리케이션 서버는 요청 처리 후 컨텐트를 HTTP 응답함
  • HTTP 응답에 들어있는 콘텐트는 HTML로 작성한 웹 문서 또는 이미지, 비디오 등임
• 웹 브라우저 : 돌려받은 HTTP 응답을 화면에 출력하는 기능 제공

1.4. HTTP (Hyper Text Transfer Protocol)

• 웹 브라우저와 웹 애플리케이션 서버가 통신시 사용하는 프로토콜임.
  • 통신 프로토콜, 통신 규약
  • 원거리 통신 장비 사이에서 메시지를 주고 받는 양식과 규칙의 체계를 말함.
• 클라이언트가 요청을 보내면, 서버가 응답하는 단순한 구조로 만들어짐
• 각각의 요청과 응답은 모두 독립적인 요청과 응답임.

1.5. HTTP 요청

• HTTP 메소드
  • 서버에 요청을 보내는 방법으로 총 9가지 명령으로 이루어져 있음.
  • 클라이언트는 요청시 메소드를 통해 주어진 자원에 수행하길 원하는 행동을 나타냄.
• 웹 브라우저는 GET과 POST, 2가지 메소드를 지원함
  • GET

    요청 URL에 해당하는 콘텐트(자원)을 가져옴

  • POST

    요청 URL의 콘텐트(자원)의 새로운 데이터를 보냄

---

[참고] 다른 메소드들

• PUT

  요청 URL에 변경할 데이터를 보냄

• DELETE

  요청 URL의 콘텐트(자원)을 삭제함

• HEAD

  헤더(메타 데이터)만 가져옴

• TRACE

  보낸 메시지를 다시 돌려보냄 (loop-back)

• CONNECT

  프락시에 사용하기 위해 예약된 메소드임

• PATCH

  요청 URL에 해당하는 콘텐트 중 일부 변경함

• OPTIONS

  요청 URL에 사용할수 있는 메소드를 확인함

1.6. HTTP 응답 상태코드

• 요청에 대한 응답 상태(웹 브라우저는 상태코드에 따라 동작방식을 결정함)
• 5가지 유형 (1xx, 2xx, 3xx, 4xx, 5xx)의 총 60여개 표준 상태코드가 정의되어 있음

유형	예시
1xx	100(계속) : 요청자는 요청을 계속해야 함 101(프로토콜 전환)
2xx	200(성공) : 서버가 요청을 제대로 처리했음 201(작성됨) : 성공적으로 요청되었으며 서버가 새 리소스를 작성했음
3xx	301(영구 이동) 302(임시 이동)
4xx	400(잘못된 요청) : 서버가 요청의 구문을 인식하지 못했음 404(찾을 수 없음) : 서버가 요청한 페이지를 찾을 수 없음. (서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 등)
5xx	서버 오류 500(내부 서버 오류) : 서버에 오류가 발생하여 요청을 수행할 수 없음 503(서비스를 사용할수 없음) : 현재서버를 사용할수 없음(대개 일시적인 상태)

1.7. 웹 프로그래밍

• FrontEnd : 클라이언트 중심의 프로그래밍(HTML/CSS/JS) 영역
• BackEnd : 서버를 구성하며 서비스를 제공하기 위한 서버쪽 프로그래밍 영역

1.8. 벡엔드 중심 개발

• 전통적인 웹 개발 모델
• 서버에서 모든 것을 담당하는 방식
• 자바 서블릿/JSP의 인기가 가장 높다
• 장점
  • 서비스 연동에 필요한 다양한 서버 환경에 대응할수 있음.
  • 기술이 안정적이고 검증됨
  • 기존에 개발된 시스템이 많고 레거시 시스템은 오랫동안 유지됨.
• 단점
  • 서버에 화면 갱신의 과도한 요청이 발생시 문제가 될수 있음
  • 기존의 대규모 구축된 모로리틱 아키텍쳐 방식으로 적용 => MSA (Micro Service Architecture) 방식이 확산되고 있음

1.9. 프런트엔드 중심 개발

• 클라이언트에서 HTML을 가지고 있거나, 서버로부터 화면 구성에 필요한 데이터만 자바스크립트(NodeJS)로 받아 와 화면을 조합해 보여줌

• CSR (Client Side Redering)이라고도 함.

• 장점
  • 필요한 부분의 데이터만 갱신이 가능하기 때문에 서버로부터 매번 갱신된 전체 화면을 받아올 필요가 없음.
  • 실시간 데이터 갱신이 자유로움
  • SPA (Single Page App), PWA (Progressive Web App)등의 구현에 적용할 수 있음.
  • React, Vue, Angular 등 다양한 프레임워크을 사용할 수 있음.
• 단점
  • 프런트엔드 중심 개발이라 하더라도 데이터 제공을 위한 서버는 필요함.
  • 벡엔드 작업은 당연히 존재함.
  • SSR (Server Side Redering)을 접목해야 함.

1.10. 웹 개발 트랜드

• 스프링 프레임워크가 대세.
  • 국내에서는 자바 기반 대표적인 벡엔드 개발 방식이 자리잡음.
  • 전자정부 프레임워크 역시 스프링 기반임.
• 전통적인 모놀리틱 아키텍쳐 중심 서버 운영
  • 소규모 분산 운영 방식인 MAS로 전환되기 시작함.
• NodeJS, 파이썬을 이용한 서버 프로그램 개발이 늘어나고 있음.
• on-Premise : 서버를 직접 운영하는 방식
  • Serverless : 서버를 작업을 서버내부가 아닌 클라우드 서비스로 처리

SPRING 카테고리 내 다른 글 보러가기