본문 바로가기

Spring Boot(스프링 부트)

자바 기초 문법 및 웹 이해

GDSC (Spring Boot 기초반) 활동을 다시 시작하였다!

내용은 김영한 선생님과 우아한테크를 수강 후 작성하였다

 

 

객체 지향 프로그래밍

 

객체 지향 프로그래밍
  • 컴퓨터 프로그램을 "객체들의 모임"으로 파악하고자 하는 것
  • 프로그램을 유연하게 하고 변경을 용이하게 만듦

 

 

 

객체 지향 특징
  • 추상화
  • 캡슐화
  • 상속
  • 다형성

 

 

 

다형성
역할과 구현으로 구분(분리) -> 유연하고 변경이 용이
 
ex) 자동차
- 자동차가 달라도 운전자는 영향 X

ex) 공연
- 배우는 대체 가능
  • 클라이언트는 대상의 역할(인터페이스)만 알면 됨
  • 클라이언트는 구현 대상의 내부 구조를 몰라도 됨
  • 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향 X
  • 클라이언트는 구현 대상 자체를 변경해도 영향 X

 

 

 

자바 언어
  • 다형성을 활용
    • 역할 = 인터페이스
    • 구현 = 인터페이스를 구현한 클래스, 구현 객체
  • 객체를 설계할 때 역할과 구현을 명확히 분리
  • 객체 설계시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기
  • 다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경 가능

 

 

 

다형성의 본질질
  • 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경 가능
  • 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경 가능

 

 

 

역할과 구현 분리의 한계
  • 역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생
  • 인터페이스를 안정적으로 잘 설계하는 것이 중요

 

 

 

 


 

 

 

HTTP

 

HTTP
  • Hypertext Protocol
  • 서버-클라이언트 메시지 교환 프로토콜
  • 클라이언트: Request
  • 서버: Response

 

 

 

HTTP 특성
  • Stateless
    • 세션
    • 쿠키
  • URI로 리소스 식별
  • 지속 연결

 

 

 

HTTP 메서드
  • GET
    • 특정한 리소스를 가져오도록 요청
  • POST
    • 대상 리소스에게 리퀘스트 본문을 해당 리소스의 시맨틱에 따라 처리하도록 요청
    • ex) 게시판, 블로그 같은 글 모음에 글 보내기
    • ex) 서버에 새로운 리소스 생성하기
  • PUT 
    • 대상 리소스가 없다면 생성
    • 대상 리소스가 있으면 리퀘스트의 본문대로 교체
  • PATCH
    • 리소스의 일부를 수정
  • DELETE
    • 지정한 리소스를 삭제

 

 

 

HTTP 상태 코드
  • 1XX
    • 코드를 요청을 받았고, 해당 요청에 대한 프로세스를 진행중
  • 2XX
    • 요청이 성공적으로 처리
  • 3XX
    • 요청에 대한 추가적인 처리, 동작이 필요
  • 4XX
    • 오류 코드
    • 클라이언트의 요청이 잘못됐을 때
  • 5XX
    • 오류 코드
    • 서버에 오류가 발생

 

 

 


 

 

 

API & Library & Framework

 

API(Application Programming Interface)
  • 응용 프로그램에서 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
  • 특징
    • 구현과 독립적으로 사양만 정의되어 있음
    • API에 따라 접근 권한이 필요할 수 있음
  • ex) Java API, 여러 기업들의 오픈 API

 

 

 

Library
  • 응용 프로그램 개발을 위해 필요한 기능(함수)을 모아 놓은 소프트웨어
  • 특징
    • 독립성을 가짐
    • 응용 프로그램이 능동적으로 라이브러리를 사용
      • 개발자가 작성한 응용 프로그램에 라이브러리를 호출하여 처리
  • ex) Apache Commons, Guava, Lombok, jQuery

 

 

 

Framework
  • Frame: 틀, 뼈대 + work: 일(하다) = "틀 안에서 일을 하다."
  • 응용 프로그램이나 소프트웨어의 솔루션 개발을 수월하게 하기 위해 제공된 소프트웨어 환경
  • 특징
    • 상호협력하는 클래스와 인터페이스의 집합
    • 응용 프로그램이 수동적으로 프레임워크에 의해 사용됨
      • 개발자가 작성한 비즈니스 로직이 Spring Framework에 호출되어 처리
  • ex) Spring Framework, Junit, Ruby on Rails

 

 

 

API vs Library vs Framework
  • Library와 API의 차이점
    • 구현 로직의 유뮤
  • Library와 Framwork의 차이점
    • 응용 프로그램의 흐름 주도권을 누가 가지고 있느냐

 

 

 


 

 

 

REST API

 

REST API
  • 일반적인 인식
    • URI를 통해 자원을 지정
    • HTTP 메서드: 자원에 대한 행위 표현
  • Fielding(REST 용어 창시자)에게 있어서 REST API 의미
    • REST 아키텍쳐 스타일에 부합하는 API
    • REST API라고 부를 수 있는 최소 조건
      1. 자원에 대한 식별
      2. 표현을 통한 자원에 대한 조작
      3. 자기 서술적 메시지
      4. HATEOAS(hypermedia as the engine of application state)

 

 

 

자원에 대한 식별
  • 자원
    • 이름을 지닐 수 있는 모든 정보
    • 개념적인 대상
    • ex) 문서, 이미지, 자원들의 집합, 실존하는 대상
  • 자원은 객체
    • 상태는 변화 가능함
    • 식별을 하기 위해서는 변하지 않는 식별자 필요(고유한 식별자 부여의 필요)
    • 따라서 URI를 통해 자원을 식별해야 함(고유한 식별자로 URI를 사용)

 

 

 

표현을 통한 자원에 대한 조작
  • 표현: 특정한 상태의 자원에 대한 표현
    • 자원은 다양한 방식으로 표현 가능
    • ex) 문서, 파일, HTTP 메시지 엔티티 등
  • REST: 자원에 대한 표현 전송
    • Representation State Transfer(표현된 (자원의) 상태 전송)
      • 자원의 현재 상태
      • 자원의 기대되는 상태

 

 

 

자기 서술적 메시지
  • 메시지는 스스로에 대해 설명해야 함
    • 클라이언트와 서버 사이의 컴포넌트들은 메시지의 내용을 참고하여 적절한 작업 수행
  • Host 헤더에 도메인명 기재 필요
    • 도메인명 정보의 필요성(가상호스트 문제)
      • 하나의 IP 주소에 복수의 도메인명 존재 가능
      • IP 주소만으로는 요청 대상을 찾아낼 수 없음
  • 캐쉬 관련 헤더를 통한 캐쉬 전략 지정
    • 클라이언트와 서버 사이의 특정 컴포넌트에 일정 기간 동안 캐쉬에 넣는 경우 두 번째 요청부터는 해당 컴포넌트로부터 이 캐쉬된 데이터를 곧바로 제공받을 수 있음
    • 캐쉬 관련 헤더들을 메시지에 포함시킴으로써 캐쉬 관련 동작들을 마음껏 커스터마이징 가능

 

 

 

HATEOAS(hypermedia as the engine of application state)
  • 하이퍼미디어를 통한 앱 상태 변경
  • HTML과 같은 하이퍼미디어를 통해 클라이언트가 애플리케이션의 상태를 변경할 수 있는 인터페이스를 제공해야 함
  • 접근할 수 있는 페이지들 이외에 숨겨진 페이지(숨겨진 경로)가 존재한다면 HATEOAS에 위배!
    • 일반적으로 우리가 설계하는 백엔드 서버의 API는 HATEOAS를 위배한 경우가 기본적으로 많음
    • JSON에 서버에 보낼 수 있는 요청들에 대한 정보를 포함시켜서 클라이언트에 전달 가능하면 HATEOAS에 위배되지 않음!
      • 프론트엔드에서 JSON에 담긴 정보를 활용 가능 -> HATEOAS에 위배되지 않음!

 

 

 


 

 

 

마치며... 객체지향과 HTTP, (REST) API, Library, Framework에 대해서 학습하였다.

API와 Library, 그리고 Framework에 대한 설명과 특징, 차이점이 인상깊었다. 발표자분의 말이 머리에 다 쏙쏙 들어오는 느낌이었다. API도 직접 사용해보지 않아서 앞으로 프로젝트를 할 때 되게 부담이 많이 되었는데, 간단하게 설명을 정리해주셔서 API도 다루어보고 싶은 자신감도 생기게 되었다!

저번 학기에 Spring boot에 대해 조금 학습해서인지 덜 낯설었다. 아예 손을 놓고 있어서 많이 리셋된 거 같지만 다시 꾸준히 공부하며 블로그 포스팅을 이어나가려고 한다!