2.1 HTTP/HTTPS와 REST API (서버 간 통신)

김찬미·2024년 5월 29일

[Book] 스프링 부트 핵심 가이드

목록 보기

3/45

어떤 포털 사이트를 개발한다고 가정해보자. 그 사이트 속에는 블로그, 카페, 메일 등 다양한 기능이 있는데, 이것들을 모두 하나의 애플리케이션에 통합하면 어떻게 될까? 서비스를 이렇게 구성한다면 서버를 업데이트하거나 한 기능을 유지보수 할 때마다 사이트를 중지시켜야 한다. 당연히 개발에 보수적인 입장을 취할 수 밖에 없고 서비스 자체의 규모도 커지기 때문에 서비스 구동 시간도 훨씬 길어진다.

이 같은 문제를 해결하기 위해 나온 것이 마이크로서비스 아키텍처(MSA)이다. 마이크로서비스 아키텍처는 단어 그대로 서비스 규모를 작게 나누어 구성한 아키텍처를 의미한다. 앞에서 예로 든 포털 사이트에 적용한다면 블로그 프로젝트, 카페 프로젝트, 메일 프로젝트 등 애플리케이션을 기능 별로 나누어 개발하게 된다.

단일 서비스로 구성된 사이트는 내부 메서드 호출 등을 통해 원하는 자원을 가져와 사용할 수 있지만 서비스 기능별로 구분한 B 포털 사이트의 경우 각 서비스간 통신해야 하는 경우가 발생한다. 이러한 상황에서의 통신을 '서버 간 통신'이라고 한다.

서버 간 통신

서버 간 통신은 분산 시스템에서 서버들이 서로 데이터를 주고받기 위해 사용되는 방법들을 의미한다. 좀 더 자세하게 설명하자면 한 서버가 다른 서버에 통신을 요청하는 것을 의미하며, 한 대는 서버, 다른 한 대는 클라이언트가 되는 구조이다. 몇 가지 프로토콜에 의해 다양한 통신 방식을 적용할 수 있지만 가장 많이 사용되는 방식은 HTTP/HTTPS 방식이다.

HTTP/HTTPS

서버 간 통신에서 HTTP/HTTPS 방식은 널리 사용되는 프로토콜이다. 이 방식은 주로 웹 애플리케이션과 API 통신에서 많이 사용되며, REST API가 대표적이다. HTTP와 HTTPS는 같은 프로토콜을 사용하지만, HTTPS는 보안을 강화한 방식이다.

HTTP (HyperText Transfer Protocol)

웹 브라우저와 웹 서버 간의 통신에 사용되는 기본 프로토콜. 클라이언트가 서버에 요청(request)을 보내면, 서버는 이에 대한 응답(response)을 반환한다. (Request - Response 구조)

HTTPS (HTTP Secure)

HTTP에 보안 계층인 SSL/TLS를 추가한 프로토콜. 데이터가 전송되는 동안 암호화되어 도청, 변조, 위조를 방지한다.

통신 과정

클라이언트 요청 : 클라이언트(서버 간 통신에서는 다른 서버)가 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 서버에 요청을 보낸다.
서버 처리 : 서버는 요청을 처리하고 적절한 응답을 생성한다.
서버 응답 : 서버는 HTTP 응답 코드를 포함한 응답 메시지를 클라이언트에 보낸다. 응답 메시지에는 상태 코드, 헤더, 바디 등이 포함된다.

HTTP 메서드

GET : 리소스를 조회할 때 사용한다. 데이터의 변경 없이 서버로부터 데이터를 가져온다.
POST : 서버에 데이터를 제출할 때 사용한다. 일반적으로 리소스를 생성할 때 사용된다.
PUT : 서버의 리소스를 업데이트할 때 사용한다.
DELETE : 서버의 리소스를 삭제할 때 사용한다.
PATCH : 리소스의 일부를 업데이트할 때 사용한다.

요청 및 응답 예시

요청 예시 (GET) :

GET /api/users HTTP/1.1  # HTTP 메서드(GET),요청 대상 리소스(/api/users)
Host: example.com  # 요청을 보내는 서버의 호스트명(도메인)
Accept: application/json  # 클라이언트가 서버로부터 받고자 하는 응답의 콘텐츠 타입

응답 예시:

HTTP/1.1 200 OK  # HTTP 버전(1.1), 응답 상태 코드(200 OK)
Content-Type: application/json
Content-Length: 85  # 응답 본문의 길이(바이트 단위)

{
  "users": [
    {"id": 1, "name": "Alice"},
    {"id": 2, "name": "Bob"}
  ]
}

HTTP/HTTPS 통신의 장점

표준화된 프로토콜 : HTTP는 전 세계적으로 표준화되어 있어, 다양한 클라이언트와 서버 간의 상호운용성이 뛰어나다.
단순성 : 구조가 단순하여 구현과 사용이 쉽다. RESTful API는 HTTP 프로토콜의 단순성과 일관성을 극대화한 예이다.
확장성 : URI를 통해 리소스를 식별하고, 다양한 HTTP 메서드를 통해 리소스를 조작할 수 있어 확장성이 높다.
플랫폼 독립적 : HTTP는 모든 주요 프로그래밍 언어와 플랫폼에서 지원된다.

결론

HTTP/HTTPS는 서버 간 통신에서 중요한 역할을 하며, REST API를 통해 이를 효과적으로 구현할 수 있다. 보안을 위해 HTTPS를 사용하고, 적절한 상태 관리와 에러 처리를 통해 신뢰성 높은 통신을 구현하는 것이 중요하다.

REST API

☝ (REST API 동작 방식)
REST API는 대중적으로 가장 많이 사용되는 애플리케이션 인터페이스이다. 이 인터페이스를 통해 클라이언트는 서버에 접근하고 자원을 조작할 수 있다. 이번엔 REST의 형식 및 규칙을 알아보자.

REST란?

REST란 'Representational State Transfer'의 약자로, 웹 서비스 설계를 위한 아키텍처의 한 형식이다. 주고받는 자원(Resource)에 이름을 규정하고 URI에 명시해 HTTP 메서드(GET,POST,PUT,DELETE)를 통해 해당 자원의 상태를 주고받는 것을 의미한다.

REST API란?

API는 'Application Programming Interface'의 약자로, 애플리케이션에서 제공하는 인터페이스를 의미한다. API를 통해 서버 또는 프로그램 사이를 연결할 수 있다. REST API는 REST 아키텍처를 따르는 시스템/애플리케이션 인터페이스라고 볼 수 있다. REST 아키텍처를 구현하는 웹 서비스를 'RESTful하다'라고 표현한다.

REST vs. REST API

REST는 웹 서비스 설계를 위한 아키텍처 스타일로, HTTP 외에도 다양한 프로토콜에서 사용할 수 있는 일반적인 원칙이다. REST API는 REST 원칙을 구현한 특정한 웹 서비스이다. 따라서, REST는 개념적이고 철학적인 설계 원칙을 나타내고, REST API는 이 원칙을 실제로 구현한 웹 서비스라고 이해할 수 있다.

REST의 특징

1. 유니폼 인터페이스

유니폼 인터페이스란 '일관된 인터페이스'를 의미한다. 즉, REST 서버는 HTTP 표준 전송 규악을 따르기 때문에 어떤 프로그래밍 언어로 만들어졌느냐와 상관없이 플랫폼 및 기술에 종속되지 않고 타 언어, 플랫폼, 기술 등과 호환해 사용할 수 있다.

2. 무상태성

무상태성이란 서버에 상태 정보를 따로 보관하지 않거나 관리하지 않는다는 의미이다. 서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키 정보를 별도로 보관하지 않는다. 그렇기에 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리한다. 이렇게 구성된 서비스는 서버가 불필요한 정보를 관리하지 않으므로 비즈니스 로직의 자유도가 높고 설계가 단순하다.

3. 캐시 가능성

REST는 HTTP 표준을 그대로 사용하므로 HTTP의 캐싱 능력을 적용할 수 있다. 이 기능을 이용하기 위해서는 응답과 요청이 모두 캐싱 가능한지(Cacheable) 명시가 필요하며, 응답에는 캐시 가능한 기간을 명시하는 메타데이터가 포함되어야 한다. 캐싱이 가능한 경우 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용한다. 이 기능을 이용하면 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선된다.

4. 레이어 시스템

REST 서버는 네트워크 상의 여러 계층으로 구성될 수 있다. 그러나 서버의 복잡도와 관계없이 클라이언트는 서버와 연결되는 포인트만 알면 된다.

5. 클라이언트-서버 아키텍처

REST 서버는 API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계한다. 클라이언트와 서버는 서로 독립적이며 이 구성은 서로에 대한 의존성을 낮추는 기능을 한다.

RESTful URI 설계 규칙

REST API를 설계하는 데엔 몇 가지 규칙이 있다.

URL 규칙

1. URI의 마지막에는 '/'를 포함하지 않는다.

옳은 예⭕) http://localhost.com/product
잘못된 예❌) http://localhost.com/product/

2. 언더바(_) 대신 하이픈(-)을 사용한다.

옳은 예⭕) http://localhost.com/product-name
잘못된 예❌) http://localhost.com/product_name

3. URL에는 행위(동사)가 아닌 결과(명사)를 표함한다.

옳은 예⭕) http://localhost.com/product/123
잘못된 예❌) http://localhost.com/delete-product/123
행위는 HTTP 메서드로 표현할 수 있어야 한다.

4. URI는 소문자로 작성해야 한다.

URI 리소스 경로에는 대문자 사용을 피하는게 좋다.
일부 웹 서버의 운영체제는 리소스 경로 부분의 대소문자를 다른 문자로 인식하기 때문이다.

5. 파일의 확장자는 URI에 포함되지 않는다.

HTTP에서 제공하는 Accept 헤더를 사용하자.

김찬미

백엔드 개발자

이전 포스트

1.2 스프링 부트 ( vs. 스프링과의 차이점)

다음 포스트