Kotlin으로 개발하는 Spring Boot Web MVC #0

Kotlin으로 개발하는 Spring Boot Web MVC #0

목차

 

Why Kotlin?

• JVM 언어 / Java와 100% 호환.
  • 코틀린 <-> 자바 서로 임포트해서 사용할 수 있음.
• 현대 언어 지향
• 코틀린의 Elvis Operation을 통해 안정적으로 NULL Point 대응 가능.
• Java에 비해 간결한 코드.
• 코틀린만의 표준 함수.
• 타입추론의 편리함 (Java10에서는 지원)

Spring Boot

단순히 실행되며, 프로덕션 레벨의 애플리케이션을 쉽게 만들 수 있음.

Spring Framework의 구성 설정이 거의 필요 하지 않음.

java -jar로 실행하는 Java 애플리케이션을 만들 수 있음.

Web 개론

Web이란?

World Wide Web, WW, W3이라 불리는데 인터넷에 연결된 컴퓨터를 통해 사람들이 정보를 공유할 수 있는 전 세계적인 정보 공간을 말함.

 

Web의 용도를 우리가 제일 많이 접하는 부분으로 정리.

• Web Site (Google, Naver, Daum ...)
• User Interface (Chrome, Safari, Explorer ...)
• API (Application Programming Interface)

Web의 기반

• HTTP (Hypertext Transfer Protocol)
  • 애플리케이션 컨트롤
  • Get, Post, Put ... 등의 메서드 존재
• URI (Uniform Resource Identifier)
  • 리소스 식별자
  • 특정 사이트, 특정 쇼핑 목록 ...
  • 모든 정보에 접근 할 수 있는 정보
• HTML (Hyper Text Markup Language)
  • 하이퍼미디어 포맷
  • XML을 바탕으로한 범용 문서 포맷
  • 웹 브라우저에서 사용자가 알아보기 쉬운 형태로 표현

REST

REST (Representational State Transfer, 자원의 상태 전달)

네트워크 아키텍처 원리

• Client, Server: 클라이언트와 서버가 서로 독립적으로 분리되어져 있어야 함.
• Stateless: 요청에 대해서 클라이언트의 상태가 서버에 저장하지 않음.
• 캐시: 클라이언트는 서버의 응담을 캐시 할 수 있어야 함.
  • 캐시를 통해 응답을 재사용할 수 있어야 하며, 이를 통해 서버의 부하를 낮춤.
• 계층화: 서버와 클라이언트 사이에, 방화벽, 게이트웨이, Proxy 등 다계층 형태를 구성할 수 있어야 하며, 확장 할 수 있어야 함.
• 인터페이스 일관성: 아키텍처를 단순화시키고 작은 단위로 분리하여서, 클라이언트와 서버가 독립적으로 개선될 수 있어야 함.
  • 자원 식별: 웹 기반의 REST에서는 리소스 접근을 URI를 사용.
  • 메시지를 통한 리소스 조작: 리소스 타입을 알려주기 위해 header 부분에 content-type을 통해서 어떠한 타입인지 명시 가능.
  • 자기서술적 메시지: 요청하는 데이터가 어떻게 처리 되어야 하는지 충분한 데이터를 포함 할 수 있어야 함.
    • HTTP 기반의 REST에서는 HTTP Method와 Header의 정보로 이를 표현.
  • 애플리케이션 상태에 대한 엔진으로서 하이펑미디어: HATOS
• Code On Demand (Optional): 자바 애플릿, 자바스크립트, 플래시 등 특정기능을 서버가 클라이언트에 코드를 전달하여 실행 할 수 있어야 함.

URI

• URI (Uniform Resource Identifier)
  • 인터넷에서 특정 자원을 나타내는 주소값. 해당 값은 유일.
• URL (Uniform Resource Locator)
  • 인터넷 상에서의 자원, 특정 파일이 어디에 위치하는지 식별 하는 주소

-> URL은 URI의 하위 개념.

URI 설계원칙 (RFC-3986)

• 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용.
• URI 마지막 문자로(/)는 포함하지 않음.
• 하이픈(-)은 URI의 가독성을 높이는데 사용.
• 밑줄(_)은 사용하지 않음.
• URI 경로에는 소문자가 적합.
• 파일 확장자는 URI에 포함하지 않음.
• 프로그래밍 언어에 의존적인 확장자를 사용하지 않음.
• 구현에 의존적인 경로를 사용하지 않음.
• 세션 ID를 포함하지 않음.
• 프로그래밍 언어의 메서드명을 이용하지 않음.
• 명사에 단수형 보다는 복수형을 사용해야 함.
  • 컬렉션에 대한 표현은 복수로 사용.
• 컨트롤러 이름으로는 동사나 동사구를 사용.
• 경로 부분 중 변하는 부분은 유일한 값으로 대체.
  • https://kotlin.example.co.kr/vehicles/suv/q7/{car-id}/users/{user_id}/release
  • https://kotlin.example.co.kr/vehicles/suv/q7/117/users/0n1dev/release
• CRUD 기능을 나타내는것은 URI에 사용하지 않음.
• URI Query Parameter 디자인
  • URI 쿼리 부분으로 컬렉션 결과에 대해서 필터링 할 수 있음.
    • https://kotlin.example.co.kr/vehicles/suv?model=q7
  • URI 쿼리는 컬렉션의 결과를 페이지로 구분하여 나타내는데 사용.
    • https://kotlin.example.co.kr/vehicles/suv?page=0&size=10&sort=asc
• API에 있어서 서브 도메인은 일관성 있게 사용해야 함.
• 클라이언트 개발자 포탈 서브 도메인은 일관성 있게 만듬.

HTTP (추후 깊게 다시 공부)

• Hyper Text Transfer Protocol 로 RFC-2616에서 규정된 Web에서 데이터를 주고 받는 프로토콜.
• 이름에는 하이퍼 텍스트 전송용 프로토콜로 정의되어 있지만 실제로는 HTML, XML, JSON, Image 등 다양한 형태의 데이터를 전송 할 수 있음.
• HTTP는 TCP를 기반으로한 REST의 특징을 모두 구현하고 있는 Web 기반의 프로토콜 (HTTP 3.0 부터는 UDP... 추후 공부)
• HTTP는 메세지를 주고 (Request) 받는 (Response) 의 형태의 통신 방식.
• HTTP Method
  • GET
    • 리소스 취득
  • POST
    • 리소스 생성, 추가
  • PUT
    • 리소스 갱신, 생성
  • PATCH
    • 리소스 갱신
  • DELETE
    • 리소스 삭제
  • HEAD
    • 헤더 데이터 취득
  • OPTIONS
    • 지원하는 메서드 취득
  • TRACE
    • 요청 메세지 반환
  • CONNECT
    • 프록시 동작의 터널 접속으로 변경
• HTTP Status Code
  • 1XX
    • 처리중
  • 2XX
    • 성공
  • 3XX
    • 리다이렉트
  • 4XX
    • 클라이언트 에러
  • 5XX
    • 서버 에러