[강의] 모든 개발자를 위한 HTTP 웹 기본 지식

HTTP 상태 코드

일시적 리다이렉션

• 302 Found: 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY).
• 307 Temporary Redirect: 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안됨.
• 303 See Other: 리다이렉트시 요청 메서드가 GET으로 변경

기타 리다이렉션

• 300 Multiple Choices: 요청에 가능한 응답이 두 개 이상 있음을 나타냄.
• 304 Not Modified: 클라이언트에게 리소스가 수정되지 않았음을 알려줌. 수정되지 않았다면 캐시를 재사용하도록 유도함.

클라이언트 오류

• 400 Bad Request: 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음.
• 401 Unauthorized: 클라이언트가 해당 리소스에 대한 인즈잉 필요함.
• 403 Forbidden: 서버가 요청을 이해했지만 승인을 거부함.
• 404 Not Found: 요청 리소스를 찾을 수 없음.

서버 오류

• 500 Internal Server Error: 서버 문제로 오류 발생, 애매하면 사용
• 503 Service Unavailable: 서비스 이용 불가

HTTP 헤더

HTTP 전송에 필요한 모든 부가 정보

표현(Representation)

• Content-Type: 표현 데이터의 형식
• Content-Encoding: 표현 데이터의 압축 방식
• Content-Language: 표현 데이터의 자연 언어
• Content-Length: 표현 데이터의 길이

콘텐츠 협상(Content negotiation)

• Accept: 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
• Accept-Language: 클라이언트가 선호하는 자연 언어

• 우선 순위를 매겨 우선으로 처리할 콘텐츠 지정 가능

[강의] 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

웹 애플리케이션 이해

웹 서버(Web Server)

• HTTP 기반으로 동작
• 정적 리소스 제공, 기타 부가기능

웹 애플리케이션 서버(WAS; Web Application Server)

• HTTP 기반으로 동작
• 웹 서버 기능(정적 리소스 제공 기능)을 포함한 기능
• 프로그램 코드를 실행해서 애플리케이션 로직 수행

웹 시스템 구성

• WAS -> DB
  • WAS가 너무 많은 역할을 담당, 서버 과부화 우려
  • 에러 화면 띄우기 불가능
• Web Server -> WAS -> DB
  • 정적 리소스는 웹 서버가 처리하고 동적 리소스는 WAS가 처리
  • WAS에 동적 리소스를 요청했을 때 응답이 없으면 웹 서버에서 정적 리소스 에러 화면 띄우기 가능
  • 어떤 리소스의 비중이 많냐에 따라 웹 서버 혹은 WAS 증설 가능

서블릿

• 의미있는 비스니스 로직을 제외한 나머지 부분 생략 가능
• HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
• HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse

• 흐름
  • WAS가 HTTP 요청 메시지를 기반으로 request와 response 객체 생성 및 helloServlet 서블릿 객체 호출
  • 개발자는 request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용
  • 개발자는 response 객체에서 HTTP 응답 정보를 편리하게 입력
  • WAS가 response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성

서블릿 컨테이너

• 서블릿을 지원하는 WAS
• 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
• 서블릿 객체는 싱글톤으로 관리
• 동시 요청을 위한 멀티 쓰레드 처리 지원

동시 요청 - 멀티 쓰레드

• 서블릿 객체는 스레드에 의해 실행됨.
• 스레드
  • 애플리케이션 코드를 하나하나 순차적으로 실행하는 것
  • 한번에 하나의 코드 라인만 수행가능.

• 하나의 스레드에 다중 요청
  • 모든 요청이 제대로 작동 안할 수 있음.
• 요청마다 스레드 생성
  • 스레드 생성에 필요한 자원이 너무 비쌈.
  • 스레드 생성에 제한이 없어서 서버가 죽을 수 있음.
• 스레드 풀
  • 필요한 스레드를 스레드 풀에 보관하고 관리함.
  • 스레드가 필요하면, 이미 생성되어 있는 스레드를 스레드 풀에서 꺼내서 사용.

• 멀티 스레드에 대한 부분은 WAS가 처리하므로 개발자는 신경쓰지 않아도 됨.

[책] 객체지향의 사실과 오해

기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적임.

기능 설계와 구조 설계

• 기능(function): 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞춤.
• 구조(structure): 제품의 형태가 어떠해야 하는지에 초점을 맞춤.

소프트웨어가 사용자에게 가치 있는 이유

사용자가 필요로 하는 기능을 제공하기 때문.
-> 개발자는 사용자가 무엇을 원하는지, 그리고 사용자가 원하는 것을 만족시키기 위해 시스템이 어떤 기능을 제공해야 하는지에 초점을 맞춰야 함.

훌륭한 기능: 훌륭한 소프트웨어를 만드는 충분조건
훌륭한 구조: 훌륭한 소프트웨어를 만드는 필요조건

요구사항이 변경되는 상황이면 설계가 중요함.
-> 요구사항에 대비할 수 있는 코드를 작성해야 하며, 안정적인 구조를 중심으로 설계해야 함.

객체지향 접근방법: 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배함.
시스템 기능은 더 작은 책임으로 분할되고 적절한 객체에게 분배되기 때문에 기능이 변경되더라도 객체 간의 구조는 그대로 유지됨.

객체를 이용해 지도를 만들어라.

두 가지 재료: 기능과 구조

• 사용자에게 제공할 '기능'
  • 사용자가 자신의 목표를 달성하기 위해 사용할 수 있는 시스템의 서비스
• 기능을 담을 안정적인 '구조'
  • 시스템의 기능을 구현하기 위한 기반으로, 기능 변경을 수용할 수 있도록 안정적이어야 함.

재료를 구하는 곳

• 구조는 사용자나 이해관계자들이 도메인(domain)에 관해 생각하는 개념과 개념들 간의 관계로 표현함.
• 기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현함.

• 유스케이스 모델링: 기능을 수집하고 표현하기 위한 기법
• 도메인 모델링: 구조를 수집하고 표현하기 위한 기법
  모델링 활동의 결과물을 각각 유스케이스와 도메일 모델이라고 함.

안정적인 재료: 구조

도메인 모델

• 도메인: 사용자가 프로그램을 사용하는 대상 분야
• 모델: 대상을 단순화해서 표현함.
  • -> 대상을 추상화하고 단순화한 것.
• 도메인 모델: 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태

소프트웨어의 도메인이 무엇이건 상관없이 그곳에는 항상 도메인과 관련된 사람들이 도메인을 바라보는 모델이 존재함.

멘탈 모델

사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 갖는 모형
도메인 모델은 이해관계자들이 바라보는 멘탈 모델임.

[멘탈 모델의 세 가지 측면]

• 사용자 모델: 사용자가 제품에 대해 가지고 있는 개념들의 모습
• 디자인 모델: 설계자가 마음 속에 갖고 있는 시스템에 대한 개념화
• 시스템 이미지: 최종 제품
  -> 디자인 모델을 기반으로 만든 시스템 이미지가 사용자 모델을 정확하게 반영하도록 노력해야 함.

도메인 모델은 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지를 포괄하도록 추상화한 소프트웨어 모델임.
-> 도메인 모델 = 소프트웨어에 대한 멘탈 모델

이러한 측면을 모두 모델링할 수 있는 모델링 패러다임이 객체지향임.

표현적 차이

소프트웨어 객체는 현실 객체에 대한 추상화가 아닌 은유임.
-> 소프트웨어 객체는 현실 객체가 갖지 못한 특성을 가질 수도 있고 현실 객체가 하지 못하는 행동을 할 수도 있음.

소프트웨어 객체가 현실 객체를 왜곡한다고 할지라도 소프트웨어 객체는 현실 객체의 특성을 토대로 구축함.
-> 은유를 통해 현실 객체와 소프트웨어 객체 사이의 차이를 최대한 줄이는 것

은유를 통해 투영해야 하는 대상: 사용자가 도메인에 대해 생각하는 개념들 -> 도메인 모델
-> 소프트웨어 객체는 그 대상이 현실적인지, 현실적인지 않은지에 상관없이 도메인 모델을 통해 표현되는 도메인 객체들을 은유해야 함.
=> 표현적 차이는 줄어들 것이며, 사용자의 멘탈 모델이 그대로 코드에 녹아 스며들게 될 것임.

불안정한 기능을 담는 안정적인 도메인 모델

도메인 모델의 핵심: 사용자가 도메인을 바라보는 관점을 반영해 소프트웨어를 설계하고 구현하는 것.
-> 관점을 반영해야 하는 이유: 사용자들이 누구보다도 도메인의 '본질적인' 측면을 가장 잘 이해하고 있기 때문
도메인을 구성하는 중요한 개념과 개념 간의 관계를 가장 잘 알고 있는 사람들임.

핵심: 안정적인 구조를 제공하는 도메인 모델을 기반으로 소프트웨어의 구조를 설계하면 변경에 유연하게 대응할 수 있는 탄력적인 소프트웨어를 만들 수 있음.