Published on

BackEnd 스터디 1주차

Authors
  • avatar
    Name
    ywj9811
    Twitter

REST API

REST API 많이 들어본 단어일 것이다. 정확하게 무엇을 의미할까?

‘REST’ 란…

image “Representational State Transfer” 의 약자로 자원을 이름으로 구분하여 해당 자원의 상태 및 정보를 주고 받는 모든 것을 의미한다.

즉,

  1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
  2. HTTP Method(POST, GET, PUT, DELETE, PATCH)를 통해
  3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미한다.

REST 구성 요소

  1. 자원(Resource) : HTTP URI
  2. 자원에 대한 행위(Verb) : HTTP Method
  3. 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

REST의 특징

  1. Server-Client 의 구조
    1. 자원 보유 = Server, 자원 요청 = Client
  2. Stateless (무상태)
    1. HTTP 프로토콜이 Staless Protocal이기에 마찬가지로 무상태성이다.
    2. 즉, 서버는 각각의 요청을 완전한 별개의 것으로 판단하고 처리한다.
  3. Cacheable (캐시 처리 가능)
    1. 대량의 요청을 효율적으로 처리하기 위해서 캐시가 사용될 수 있다.
  4. Layered System (계층화)
    1. 보안, 확장과 같은 부분을 향상시킬 수 있으며 구조적 유연성을 갖출 수 있다.
  5. Uniform Interface (인터페이스 일관성)

이렇게 5가지의 특징이 있다.

REST의 장단점

장점

  • HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
  • HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
  • Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
  • REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
  • 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
  • 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

  • 표준이 자체가 존재하지 않아 정의가 필요하다.
  • HTTP Method 형태가 제한적이다.
  • 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
  • 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)

여기까지 REST에 대한 정의와 특징 그리고 장단점을 알아 보았는데 REST API는 무엇일까

‘REST API’ 란…

image REST API란 말 그대로 REST의 원리를 따르는 API를 의미한다.

이러한 REST API를 올바르게 설계하기 위해서는 몇가지 규칙을 지켜야 한데 이에 대해서 알아볼 것이다.

REST API 설계 예시

  1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하도록 한다.

    Bad Example: http://ywj9811.com/Running
Good Example: http://ywj9811.com/run

  2. 마지막에는 슬래시(/)를 포함하지 않는다.

    Bad Example: http://ywj9811.com/test/
Good Example: http://ywj9811.com/test

  3. 언더바 대신 하이폰을 사용한다.

    Bad Example: http://ywj9811.com/bad_test
Good Example: http://ywj9811.com/good-test

  4. 파일 확장자의 경우 URI에 포함하지 않는다.

    Bad Example: http://ywj9811.com/test.png
Good Example: http://ywj9811.com/test

  5. 행위를 포함하지 않는다.

    Bad Example: http://ywj9811.com/delete_test
Good Example: http://ywj9811.com/test

HTTP (HyperText Transfer Protocol)

텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고 받을 수 있는 프로토콜이다.

즉, HTTP는 데이터를 주고 받을 때 사용하는 규약으로 모든 프로그램이 이 규약에 맞춰서 개발을 하게 되면 서로 정보를 교환할 수 있게 되는 것이다.

HTTP의 특징?

HTTP의 특징은 위의 REST가 HTTP 프로토콜을 따르기 때문에 REST의 특징과 유사한 부분이 많다.

그래도 다시 한번 살펴보자면

  1. Server - Client 구조
  2. TCP / IP를 이용하는 응용 프로토콜
    1. IP를 통해 지정한 IP 주소에 도달하게 해주지만 비신뢰성, 프로그램 구분 불가능과 같은 한계가 있었다.
    2. 이를 TCP가 연결 지향과 PORT 번호를 통한 프로그램 구분을 하여 해결해 주었다.
    3. TCP 80 포트를 사용해 연결을 할 수 있다.
  3. Stateless (무상태)
    1. 이전의 상태를 기억하지 못하기 때문에 서버가 클라이언트의 상태를 보존하지 않는다.
    2. 장점 : 서버 확장성
    3. 단점 : 클라이언트가 추가 데이터 전송해야 할 수 있다.
  4. 비연결성
    1. 요청, 응답을 마치고 나면 TCP/IP 연결을 종료한다

정리해보면, HTTP는 데이터를 주고 받을 때 사용하게 되는 통신 규약이며, TCP/IP 80포트를 통해 연결한다.

HTTPS (Hyper Text Transfer Protocol Secure)

HTTP에 대해서 알아보았지만 사실 페이지 URL을 확인하면 https:// 이렇게 시작하는 것을 볼 수 있을 것이다.

HTTPS는 무엇일까?

image 기존의 HTTP의 경우 정보를 텍스트로 주고 받기 때문에 네트워크에서 전송 신호를 인터셉트하여 데이터 유출이 될 수 있다.

이때 이러한 보안 취약점을 해결하기 위해 등장한 프로콜이 HTTP + S(Secure Socket) 이다.

기본적인 모습과 목적은 HTTP와 HTTPS 모두 동일하다.

다만, HTTPS는 서버와 클라이언트 사이의 모든 통신 내용이 암호화 된다는 것이다.

HTTPS는 SSL이나 TLS 프로토콜을 통해 세션 데이터 암호화를 하며, 기본 TCP/IP 포트는 443이다.

암호화 방식

그렇다면 어떻게 암호화를 하여 사용하는 것일까?

HTTPS는 공개키 암호화 방식의 단점을 보완한 대칭키 암호화 방식을 이용한다.

참고 : 공개키 방식

  • A키로 암호화 하면 B키로 복호화 할 수 있다.
  • B키로 암호화 하면 A키로 복호화 할 수 있다.
  • 둘 중 하나를 비공개키(Private Key) 혹은 개인키라 부르고, 타인에게 제공한다. → 공개키가 공개되어도 비공개 키를 모른다면 복호화 할 수 없으니 안전하다.
  • 하지만 느리다.

참고 : 대칭키 방식

  • 동일한 키로 암호화, 복호화 모두 가능하다.
  • 대칭키는 매번 랜덤으로 생성되어 누출되어도 다음에 사용할 때는 다른 키가 사용되기 때문에 안전하다.
  • 공개키 보다 빠르다.

HTTP/1.1 HTTP/2.0 HTTP/3.0

image

😅HTTP/1.1과 HTTP/2.0 의 차이를 가장 잘 나타내는 그림이라고 한다.

HTTP/1.1 의 등장

HTTP/1.1 은 HTTP의 첫 번째 공식 표준 버전으로 GET, POST 이외에 PUT, DELETE가 생겼다.

또 하나의 TCP 연결을 재사용해 많은 콘텐츠를 전달할 수 있는 파이프라이닝 기술이 추가 되었다.

HTTP/1.1 메시지 포맷은 구현의 단순성과 접근성에 주안점을 두고 최적화가 되었다 보니까 성능이 조금 안좋다는 단점이 있었다.

바로 커넥션 하나를 통해 요청 하나를 보내고 그에 대해 응답 하나만을 받는 HTTP의 메시지 교환의 방식은 단순했지만 응답을 받아야만 새로운 요청을 보낼 수 있었기 때문에 심각한 회전 지연이 있었다.

HTTP/2.0 의 등장과 HTTP/1.1 과의 차이점

때문에 더 효율적이고 빠른 HTTP가 필요했고 이런 요구에 맞춰 구글에서 SPDY 프로토콜을 만들었다.

이후에 HTTP working group은 SPDY 프로토콜에 몇가지 보안성을 보완해 새로운 정식 HTTP를 제안했고, 이렇게 HTTP/2.0이 탄생했다.

이렇게 등장한 HTTP/2.0은 서버와 클라이언트 사이의 TCP 커넥션 위에서 동작한다.

이때 TCP 커넥션을 초기화하는 것은 클라이언트이다.

HTTP/2.0 요청과 응답은 길이가 정의된 (최대 16383 (2^14 - 1) 바이트) 한 개 이상의 프레임에 담긴다. 그리고 이 요청과 응답을 담은 프레임은 스트림을 통해 보내지는데, 하나의 TCP 커넥션 위에 여러 개의 스트림이 동시에 만들어질 수 있으므로, 여러 개의 요청과 응답을 처리하는 것이 가능해졌다.

그리고 HTTP/2.0은 여러개의 스트림에 대한 흐름 제어와 우선순위 부여 기능 또한 제공하고 있다.

또, 기존의 요청-응답과는 약간 다르게 서버 푸시를 도입하여 서버에서 필요에 따라 능동적으로 클라이언트에게 보내줄 수 있게 되었다.

어떤 차이점이 있을까

  1. 프레임

    모든 메시지를 프레임에 담아 전송하게 된다. → header + payload

  2. 스트림과 멀티플렉싱

    요청과 응답은 하나의 스트림을 통해 이루어지며 여러개의 스트림이 한번에 통신될 수 있다.

  3. 헤더 압축

    요즘에는 과거와 다르게 하나의 웹 페이지를 위해서 여러개의 헤더가 필요한데 HTTP/2.0 에서는 중복된 헤더 값들을 테이블에 저장하고 참고하는 방식으로 중복된 헤더를 줄여주고 있다.

  4. 서버 푸시

    서버가 하나의 요청에 대해 응답으로 여러개의 리소스를 보낼 수 있도록 해준다.

HTTP/3.0 의 등장

HTTP/3.0에 대해서 알아보기 이전에 잠시 구글이 개발한 QUIC를 보도록 하자.

QUIC

QUIC는 UDP를 채택해 TCP의 성능을 개선한 기술이다.

이를 통해서 전달 속도의 향상과 더불어 클라이언트와 서버의 연결 수를 최소화하고 대역폭을 예상해 패킷 혼잡을 피하는 것이 QUIC의 특징이다.

QUIC은 이전에 클라이언트가 한 번이라도 접속했던 서버라면, 별도의 정보 교환 없이 바로 데이터를 보내는 기술을 소개했다.

이 기능을 Zero RTT라고 하는데 아직 실험 단계지만 완전히 상용화된다면 HTTP/3 기술 중 가장 획기적일 것이라고 한다.

HTTP/3.0 의 등장 이유

TCP는 오래된 프로토콜로 성능보다는 기능에 초점이 맞춰져 있었다. 그러므로 멀티미디어 콘텐츠를 다양한 기기에 빠르게 전달해야 하는 상황에서 TCP의 한계를 극복하고 최적화 하는 것이 많은 기업들의 과제였다.

그렇게 위에서 설명한 QUIC를 기반으로 한 HTTP/3.0이 고안되었다.

즉, UDP를 사용하기 때문에 새로운 연결에 대해서 핸드쉐이크로 인한 지연, 패킷 손실이 다른 스트림에 미치는 영향, 패킷 손실로 인한 지연으로 부터 자유로워질 수 있다.

물론 이렇게 많은 장점이 있지만 새로운 프로토콜이다 보니 HTTP/3.0은 아직 과도기 상태라고 볼 수 있다.

Spring Framework

Spring Framework는 Java 개발에 사용되는 오픈소스 애플리케이션 프레임워크로 애플리케이션 개발을 더 쉽게 만들고, 유지보수를 간편하게 할 수 있도록 다양한 기능을 제공한다.

이러한 Spring의 특징은 다음과 같다.

  1. IoC (Inversion of Control) 컨테이너 Spring Framework의 IoC 컨테이너는 애플리케이션에서 객체의 생성, 의존성 주입 및 관리를 담당하는데 이를 통해 개발자는 객체 생성 및 관리에 대한 코드를 작성할 필요 없이 빈(Bean)을 선언하고 필요한 곳에서 사용할 수 있다. 이는 코드의 재사용성을 높이고 유지보수를 쉽게 합니다.

  2. AOP (Aspect-Oriented Programming) Spring Framework는 AOP를 지원한다. AOP는 애플리케이션에서 발생하는 여러 이벤트를 가로채서, 각각의 이벤트에 특정한 기능을 수행할 수 있도록 한다.

    예를 들어, 애플리케이션 로그를 기록하는 로깅 관심사와 같은 것들을 따로 분리하여 관리할 수 있습니다.

  3. MVC 웹 프레임워크 Spring Framework는 MVC 웹 프레임워크를 제공한다. MVC는 Model-View-Controller를 의미하며, 애플리케이션의 데이터, 프레젠테이션 로직, 컨트롤러로 분리하여 개발할 수 있도록 하는데, 이를 통해 개발자는 코드를 더욱 모듈화하고 유지보수하기 쉬운 구조로 개발할 수 있다.

  4. 테스트 지원 Spring Framework는 JUnit을 비롯한 다양한 테스트 프레임워크를 지원하는데 이를 통해 단위 테스트, 통합 테스트, 시스템 테스트 등을 수행할 수 있다.

  5. 데이터 액세스 지원 Spring Framework는 JDBC, ORM (Hibernate, MyBatis) 등 다양한 데이터 액세스 기술을 지원해준다.

  6. 보안 지원 Spring Security는 인증 및 권한 부여를 처리하기 위한 강력한 보안 프레임워크로 Spring Security를 사용하면 다양한 보안 기능을 애플리케이션에 쉽게 추가할 수 있다.

  7. 유연한 구성 Spring Framework는 XML, Annotation, JavaConfig 등 다양한 방법으로 구성할 수 있다.

  8. 대용량 및 분산 시스템 지원 Spring Framework는 대용량 및 분산 시스템에서 사용할 수 있는 다양한 기능을 제공한다. 예를 들어, Spring Integration은 메시지 기반의 애플리케이션 개발을 위한 프레임워크로서 대용량 시스템에서 사용될 수 있다.

이렇게 Spring Framework는 개발을 더 쉽게 만들고, 유지보수를 간편하게 할 수 있도록 다양한 기능을 제공하는 프레임워크이다.

다른 프레임워크와의 차이점

다른 프레임워크도 비슷한 기능을 지원하기도 하는데 왜 Spring Framework를 사용하는 것일까?

그 이유는 다음과 같다.

  1. 기능의 범위 Spring Framework는 다양한 분야에서 사용할 수 있는 다양한 기능을 제공하지만 몇몇 다른 프레임워크들은 특정 분야나 기능에 초점을 맞추고 있다. 예를 들어, Ruby on Rails는 웹 애플리케이션 개발에 초점을 맞추고, Play Framework는 비동기 처리에 특화되어 있기도 하다.
  2. 커뮤니티 규모 Spring Framework는 대규모의 개발자 커뮤니티와 생태계를 보유하고 있다.
  3. 학습 곡선 Spring Framework는 다양한 기능을 제공하므로 초기 학습 곡선이 다소 높을 수 있다. 하지만, 한 번 익혀두면 개발자가 원하는 기능을 쉽게 구현할 수 있다.
  4. 성능 Spring Framework는 대규모 시스템에서도 안정적인 성능을 발휘한다. 다른 프레임워크는 간단한 애플리케이션에서는 빠른 속도를 보이지만, 대규모 시스템에서는 성능 이슈가 발생할 수 있다.
  5. 개발 방법 Spring Framework는 DI와 AOP 등의 개념을 중심으로 한 객체지향적인 개발 방법을 제공한다. 반면에 다른 프레임워크들은 함수형 프로그래밍이나 DSL 등의 다양한 개발 방법을 지원한다.
  6. 엔터프라이즈 애플리케이션 개발 Spring Framework는 엔터프라이즈 애플리케이션 개발에 적합한 다양한 기능을 제공한다. 예를 들어, Spring Batch는 대용량 데이터 처리를 위한 프레임워크이고, Spring Integration은 메시지 기반의 애플리케이션 개발을 위한 프레임워크가 있다. 다른 프레임워크는 일반적으로 덜 엔터프라이즈적인 기능에 초점을 맞추고 있다.

즉, 핵심적으로 Spring Framework 는 대규모의 엔터프라이즈 애플리케이션 개발에 적합한 프레임워크로 다양한 분야에서 사용할 수 있는 다양한 기능과 안정적인 성능을 제공하며, 객체지향적인 개발 방법을 통해 개발자들이 더욱 안정적이고 생산적인 개발을 할 수 있도록 지원해준다.

Discuss on Twitter • View on GitHub