[MSA] SOA와의 차이점은 뭘까?, REST Maturity Model

Service를 지향하는 아키텍처 SOA와의 차이점은 무엇일까요?

 

SOA : 재사용을 통한 비용 절감

 

MSA : 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응 

-> 하나의 서비스와 연결되는 다른 서비스와의 관계를 줄인다.

만약 회원가입이라는 마이크로 서비스에서 저장된 회원 목록 데이터가 결제라는 마이크로 서비스에서 사용되기 위해서는 두 개의 서비스가 연결되거나, 결제 서비스에서 직접 회원가입 서비스에 데이터베이스에 접속해서 데이터를 사용하는 방식이 아니라, API를 통해서 데이터를 요청해서 사용해야하고, 회원가입 서비스에 문제가 생길 시에도 결제 서비스에는 직접적인 영향을 주지 않고 우회할 수 있는 서비스로 제공할 수 있도록 구현된 것이 마이크로 서비스들의 관계라고 볼 수 있다.

 

 

즉 서비스 공유를 최소화 하는 것이 MSA(Microservice Architecture)이며, 서비스 공유를 최대화하는 것이 SOA(Service-Oriented-Architecture)라고 볼 수 있다. 

 

---

Rest Maturity Model

 

REST 아키텍처 스타일을 따르는 API가 얼마나 "성숙"한지 평가하기 위한 기준이다.

 

Level 0부터 Level 3까지 나뉜다. 

 

REST Maturity Model (Level 0 ~ Level 3) Level 0: Remote Procedural Call (RPC)

 

Level 0은 RESTful 아키텍처에서 가장 기본적인 수준임. HTTP를 단순히 원격 프로시저 호출(RPC)처럼 사용함.

클라이언트가 HTTP 메서드(GET, POST 등)를 사용하긴 하지만, 실제로는 REST의 핵심 개념인 리소스를 잘 활용하지 않음.

URL이 리소스를 나타내지 않고, 일반적인 기능(예: GET/getUser, POST/createOrder)을 나타냄.

 

예시:
GET/getUser
POST/createOrder

특징:

• HTTP 메서드를 일반적인 RPC 방식처럼 사용함.
• 리소스 식별이나 HTTP의 본래 의미를 잘 사용하지 않음.
• HTTP를 제대로 활용하지 못하는 경우임.

Level 1: Resources (리소스 사용)

 

Level 1에서는 리소스를 명확하게 식별하고 HTTP 메서드를 사용하는 방법을 개선함. 

URL은 이제 리소스를 나타내며, 각각의 리소스에 대해 적합한 HTTP 메서드를 사용함.

 

예를 들어 GET은 리소스를 조회하고, POST는 리소스를 생성하는 방식.

하지만 리소스 간의 관계나 HTTP 메서드의 완전한 활용은 부족할 수 있음.

 

예시:

GET/users (모든 사용자 조회)
GET/users/{id} (특정 사용자 조회)
POST/users (사용자 생성)
PUT/users/{id} (사용자 업데이트)

 

특징:

• HTTP 메서드를 리소스와 연결하여 URI를 통해 리소스를 식별함.
• 리소스 간의 관계성(예: 링크나 내비게이션)을 표현하는 방법이나 응답 코드의 적절한 사용이 부족할 수 있음.

Level 2: HTTP Methods (HTTP 메서드의 완전한 사용)

 

Level 2는 HTTP의 메서드를 더 완벽하게 사용하고, RESTful 원칙에 좀 더 부합하는 아키텍처로 발전함.

여기서는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 리소스에 대해 정확하게 사용하며, 상태 코드도 적절하게 반환함.

또한, 클라이언트는 리소스 간의 관계를 잘 탐색할 수 있도록 적절한 HTTP 상태 코드와 헤더를 사용함.

헤더를 통해 메타데이터를 제공하며, 하이퍼미디어를 사용할 수 있지만 아직 리소스의 관계를 동적으로 탐색하는 것은 부족할 수 있음.

 

예시:
GET /users (모든 사용자 조회)
GET /users/{id} (특정 사용자 조회)
POST /users (사용자 생성)
PUT /users/{id} (사용자 업데이트)
DELETE /users/{id} (사용자 삭제)

 

특징:

• HTTP 메서드를 제대로 사용하며, 상태 코드도 적절하게 활용됨.
• 리소스 간의 관계를 표현하는 데 필요한 하이퍼미디어 링크를 추가하기 전 단계임.

Level 3: HATEOAS (Hypermedia As The Engine of Application State)

 

Level 3에서는 HATEOAS(Hypermedia As The Engine of Application State)를 완전히 지원함.

하이퍼미디어는 클라이언트가 서버와 상호작용할 때 링크를 통해 상태를 전이하고, 다른 리소스를 탐색할 수 있도록 함.

클라이언트는 서버가 제공하는 링크를 통해 애플리케이션의 흐름을 결정하며, 리소스를 탐색하고 상태를 변경함.

서버는 클라이언트에게 다음에 할 수 있는 작업을 링크 형태로 제공하여 클라이언트가 애플리케이션을 더 쉽게 탐색하고 상태를 변경할 수 있도록 함.

 

리소스..?

 

리소스는 RESTful API에서 중요한 개념임.

 

쉽게 말해서, 서버와 클라이언트 간에 주고받는 데이터나 객체가 리소스임.

예를 들어,GET /users는 모든 사용자 정보라는 리소스를 가져오는 요청이고, POST /users는 새로운 사용자라는 리소스를 생성하는 요청

 

리소스는 URL로 고유하게 식별되고, 각 리소스는 HTTP 메서드로 조작됨. 예를 들어 GET /users/{id}는 특정 사용자라는 리소스를 조회하는 요청임.

리소스 예시:
사용자 리소스: GET /users - 모든 사용자 정보
특정 사용자 리소스: GET /users/{id}
특정 사용자 정보주문 리소스: GET /orders 
모든 주문 정보특정 주문 리소스: GET /orders/{orderId} - 특정 주문 정보

 

리소스 특징:

 

• 고유 식별자: 리소스는 URL로 고유하게 식별됨. 예를 들어 /users/{id}는 특정 사용자 리소스를 나타냄.
• HTTP 메서드 사용: 리소스는 GET, POST, PUT, DELETE 같은 메서드로 조작됨.
• 데이터 구조: 리소스는 특정 데이터나 객체를 나타냄. 예를 들어, /users는 사용자의 정보를, /orders는 주문 정보를 나타냄.

 

리소스 중요한 점:

• 리소스는 단순히 데이터를 나타내는 것뿐만 아니라, 클라이언트와 서버 간의 상호작용을 위한 주요 단위임.
• RESTful API에서 리소스를 URL로 나타내고, 이를 다양한 HTTP 메서드로 처리하는 게 핵심임.

 

• Level 0: GET /getUser, POST /createOrder
  • 여기서 URL은 기능을 나타냄. /getUser는 사용자를 나타내는 리소스가 아니라, 기능인 getUser를 나타냄.
• Level 1: GET /users, POST /users
  • 여기서 URL은 리소스를 나타냄. /users는 사용자라는 리소스를 나타내고, 그 리소스를 GET이나 POST 메서드로 다루는 방식.

 

리소스는 시스템에서 관리하는 모든 데이터나 객체를 의미하고, 이를 URL로 어떻게 표현하고, HTTP 메서드로 어떻게 다룰지 고민하는 게 RESTful 설계의 핵심임.

 

 

---

 

리소스를 설계할 때 어떻게 설계하는 것이 일반적일까..?

 

보통 리소스를 설계할 때는 애플리케이션의 도메인 모델과 요구 사항을 기반으로 엔티티를 식별하고, 그에 맞는 URL 경로와 HTTP 메서드를 정의함. 리소스 설계는 RESTful API 설계 원칙을 따르며, 이를 통해 API가 직관적이고 일관되게 동작하도록 함.

 

리소스를 어떻게 설계할지에 대한 몇 가지 주요 원칙과 예시

 

1. 리소스 식별 (Identify Resources)

 

리소스를 설계하기 전에, 애플리케이션의 핵심 데이터 객체(엔티티)를 식별해야 함. 이 데이터 객체들은 대개 도메인 모델에서 중요한 역할을 하는 객체들임.

예시:

• 사용자(User)
• 주문(Order)
• 제품(Product)
• 게시물(Post)

이 객체들이 바로 리소스로 변환될 수 있음. 리소스를 식별하는 가장 기본적인 방식은 자원(리소스)을 URL로 표현하는 것임.

2. URL 설계 (Define URLs)

URL 경로는 리소스를 고유하게 식별할 수 있어야 함. 보통 리소스를 복수형으로 표기하는 것이 일반적임. 예를 들어, /users는 사용자를 나타내고, /orders는 주문을 나타냄.

예시:
/users : 사용자 목록을 조회하는 리소스
/users/{id} : 특정 사용자를 조회하는 리소스 (id는 사용자 고유 식별자)
/orders : 주문 목록을 조회하는 리소스
/orders/{id} : 특정 주문을 조회하는 리소스

3. HTTP 메서드 사용 (Use HTTP Methods)

HTTP 메서드는 각 리소스에 대해 수행할 작업을 정의함. RESTful API 설계에서 HTTP 메서드를 적절하게 사용하는 것이 매우 중요함.

• GET: 리소스를 조회
• POST: 리소스를 생성
• PUT: 리소스를 수정
• DELETE: 리소스를 삭제

예시:
GET /users: 사용자 목록을 조회
GET /users/{id}: 특정 사용자 정보 조회
POST /users: 새 사용자 생성
PUT /users/{id}: 기존 사용자 정보 수정
DELETE /users/{id}: 특정 사용자 삭제

 

4. 리소스 관계 표현 (Represent Resource Relationships)

 

리소스들 간의 관계를 명확하게 정의하는 것도 중요함. 리소스들 간의 관계는 하위 리소스(sub-resource)로 나타낼 수 있음. 예를 들어, 주문과 주문 항목은 관계가 있기 때문에 GET /orders/{id}/items처럼 하위 리소스로 표현할 수 있음.

예시:
GET /users/{id}/orders: 특정 사용자가 만든 주문 목록
POST /users/{id}/orders: 특정 사용자가 새 주문을 생성

 

5. 상태 코드 사용 (Use Status Codes)

HTTP 상태 코드를 사용하여 요청에 대한 응답 상태를 명확하게 전달해야 함. 예를 들어, 리소스를 성공적으로 조회하면 200 OK를, 리소스를 생성하면 201 Created를 반환함.

 

예시:
200 OK: 요청이 성공적으로 처리됨
201 Created: 리소스가 성공적으로 생성됨
204 No Content: 리소스가 성공적으로 삭제됨
400 Bad Request: 잘못된 요청
404 Not Found: 리소스를 찾을 수 없음

 

 

공부하면서 개발자 중심의 설계 방식보다는 해당 API를 사용하고 있는 소비자 입장에서 간단하고 명료하고 직관적인 API를 설계해야 된다는 것이 중요하다는 생각이 들었다.
 소비자는 엔드 유저를 말하는 것이 아니라 이 API를 쓰고 있는 또 다른 시스템이나 개발자를 뜻한다