Rest API란 무엇이며, RestFul 하다는 건 어떤 의미인가?

REST API와 RESTful의 개념은 웹 개발에서 자주 등장하지만, 처음 접하면 헷갈릴 수 있어요. 쉽게 풀어서 설명해볼게요.

🔹 REST API란?

REST는 “REpresentational State Transfer"의 약자예요. 2000년에 로이 필딩(Roy Fielding)이 논문에서 제안한 웹 아키텍처 스타일 중 하나죠.

즉, REST API는 이 REST 원칙에 따라 설계된 웹 API를 말해요.

🔹 REST의 핵심 개념

REST는 다음의 6가지 제약 조건을 기반으로 해요:

1. 클라이언트-서버 구조

   • 클라이언트(브라우저, 앱)와 서버는 서로 분리되어 역할을 나눔.

2. 무상태성 (Stateless)

@Mock과 @MockBean은 둘 다 테스트에서 Mock 객체를 만들기 위한 어노테이션이지만, 쓰이는 환경과 역할이 조금 달라요. 간단히 차이부터 요약하면:

🔹 @Mock (from Mockito)

• Mockito에서 제공하는 어노테이션
• **순수 단위 테스트(Unit Test)**에 사용
• Spring Context와는 무관
• 테스트 클래스 내에서 의존성을 Mock으로 주입하고 싶을 때 사용
• MockitoAnnotations.openMocks(this) 또는 @ExtendWith(MockitoExtension.class) 와 함께 사용해야 함

예시:

@ExtendWith(MockitoExtension.class)
class MyServiceTest {

    @Mock
    private MyRepository myRepository;

    @InjectMocks
    private MyService myService;

    @Test
    void testSomething() {
        // myRepository는 mock 객체
    }
}

🔸 @MockBean (from Spring Boot)

• Spring Boot Test에서 제공하는 어노테이션
• 통합 테스트(Integration Test) 시 사용
• Spring ApplicationContext에 등록된 Bean을 Mock으로 교체
• @SpringBootTest, @WebMvcTest, @DataJpaTest 같은 Spring 기반 테스트 환경에서 사용

예시:

@Mock 과 @InjectedMock

@Mock과 @InjectMocks의 차이를 알아볼게요. 이 둘은 함께 자주 쓰이지만 서로 다른 역할을 해요.

🔹 @Mock

• Mockito에서 제공
• Mock 객체를 생성해줌
• 단독으로는 그냥 가짜 객체일 뿐, 아무 데도 주입되지 않음

@Mock
private MyRepository myRepository; // 가짜 객체 생성

🔸 @InjectMocks

• 역시 Mockito에서 제공
• 테스트 대상 객체(테스트할 클래스)를 생성하고,
  그 안에 있는 의존성 필드에 @Mock으로 만든 객체들을 자동으로 주입

@InjectMocks
private MyService myService; // MyService 객체를 만들고, 내부에 있는 MyRepository 등에 @Mock 객체를 주입

✅ 간단 예시

@ExtendWith(MockitoExtension.class)
class MyServiceTest {

    @Mock
    private MyRepository myRepository;

    @InjectMocks
    private MyService myService;

    @Test
    void testSomething() {
        // myService는 실제 객체
        // myRepository는 mock 객체
        // myService 내부에서 myRepository가 사용될 때 mock이 주입됨
    }
}

📌 정리하자면:

즉, @Mock이 가짜 부품을 만드는 거고,
@InjectMocks는 그 부품을 조립해서 테스트 대상 객체를 만드는 거예요.

Mock, Stub 의 차이

mock과 stub은 테스트에서 외부 의존성을 대체하기 위해 쓰이는 객체인데, 둘은 목적과 기능 면에서 조금 달라요.

📌 요약 비교

🔹 Stub: 단순하게 리턴값만 정해놓은 가짜

• 실제 메서드 로직은 필요 없고, “이 값을 주면 이 값을 돌려줘!” 같은 간단한 대체품.
• 주로 “기존 시스템에서 이거만 제대로 동작하면 돼"라는 테스트에 사용.

when(userRepository.findById(1L)).thenReturn(Optional.of(user));

🔸 Mock: 행위(호출 여부 등)까지 확인하는 가짜

• 리턴값도 정의할 수 있지만, “정말로 이 메서드가 호출됐는가?” 같은 검증도 가능.
• verify() 같은 메서드를 통해 테스트의 정확성을 높임.

verify(userRepository, times(1)).findById(1L);

✅ 실제 테스트 예시

@Mock
UserRepository userRepository;

@InjectMocks
UserService userService;

@Test
void testUserFetch() {
    // Stub: 리턴값 지정
    when(userRepository.findById(1L)).thenReturn(Optional.of(new User("Alice")));

    // 메서드 실행
    User user = userService.getUser(1L);

    // Mock: 호출 여부 검증
    verify(userRepository, times(1)).findById(1L);
}

📎 간단 비유

• Stub: “누가 와도 무조건 이 대사만 말해!”
• Mock: “누가 오면 이 대사를 하고, 제대로 말했는지 검사도 합니다.!”

테스트 더블(Test Double) 용어 정리

• 아래는 테스트에서 자주 쓰이는 5가지 테스트 대역입니다:

🧪 테스트 더블(Test Double) 종류 요약

1. 🐣 Dummy

• 가장 단순한 형태.
• 아무 일도 하지 않고, 값만 채우는 용도.
• 테스트에 직접적 의미 없음. 없어도 테스트 통과 가능.

User dummyUser = new User(null); // 생성자 매개변수 맞추려고 넣는 용도

2. 🧪 Stub

• 호출하면 정해진 값을 리턴함.
• 동작 자체는 단순하고 검증 로직은 없음.
• 상태 기반 테스트에 사용됨.

when(userRepository.findById(1L)).thenReturn(Optional.of(new User("Alice")));

3. 🤖 Mock

• Stub처럼 리턴값을 줄 수 있지만, 추가로 호출 여부도 검증함.
• 테스트의 **행위 검증(Behavior Verification)**에 초점.

verify(userRepository, times(1)).save(any());

4. 🕵️ Spy

• 실제 객체를 감싸면서, 필요한 부분만 mock 처리 가능.
• 일부 메서드는 진짜 실행, 일부는 stub/mock 가능.
• 사용 시 조심: 진짜 의존성이 따라올 수 있음.

UserService spyService = spy(new UserService(realRepository));
doReturn("fakeName").when(spyService).getUserName();

5. 🧩 Fake

• 진짜 구현체는 아니지만, 실제로 동작하는 간단한 구현.
• 테스트용으로 가볍게 만든 진짜 비즈니스 로직을 흉내낸 것.
• 예: InMemory DB, 테스트용 메시지 큐 등

public class InMemoryUserRepository implements UserRepository {
    private Map<Long, User> db = new HashMap<>();
    public Optional<User> findById(Long id) { return Optional.ofNullable(db.get(id)); }
}

🎯 어떤 걸 언제 써야 할까?

Fake Repository 예시

Spring 환경에서 자주 쓰이는 Fake Repository 예제를 보여드릴게요.
단위 테스트에서 JPA 같은 실제 DB 연결 없이도 로직을 검증하고 싶을 때 아주 유용합니다.

MSA(Microservices Architecture)에서 trace ID와 span ID는 **분산 추적(distributed tracing)**에서 사용되는 고유 식별자들이야. 시스템 전체에서 요청의 흐름을 추적할 수 있게 해주는 핵심 개념입니다.

1. Trace ID

• 하나의 전체 요청(Request)을 식별하는 고유한 ID입니다.
• 예: 사용자가 웹에서 어떤 버튼을 클릭해서 API 요청이 들어오고, 그 요청이 여러 개의 마이크로서비스를 거쳐 처리되는 경우, 이 전체 흐름을 하나의 trace로 봅니다.
• 즉, trace ID는 **“이 요청이 어디서 시작돼서 어디까지 갔는가”**를 나타냄.

2. Span ID

• trace 안에서 **각각의 작업 단위(작은 호출 하나하나)**를 식별하는 ID입니다.
• 예: A 서비스가 B 서비스와 C 서비스를 호출하면, A-B, A-C 각각이 별도의 span이 되고, 각각에 대한 span ID가 있습니다.
• Span은 시작 시간, 종료 시간, 어떤 작업인지 등 세부 정보도 포함됩니다.

구조 예시

[Trace ID: abc123]

   ┌─────────────┐       ┌─────────────┐
   │ User Request│──────▶│ API Gateway │───┐
   └─────────────┘       └─────────────┘   │
                                           ▼
                                   ┌────────────┐
                                   │ Service A  │───┐
                                   └────────────┘   │
                                                    ▼
                                            ┌────────────┐
                                            │ Service B  │
                                            └────────────┘

• 전체 요청의 흐름이 하나의 Trace ID (abc123)를 공유하고,
• 각 서비스 간 호출은 서로 다른 Span ID를 가짐.

요약

첨언

• 실제 MSA 구현시 front end에서 api request시점부터 trace id와 span id가 채번되고
• 예를 들어, bff -> api-gateway -> user-service 를 통해 request 가 흘러간다면, 각 서비스는 동일한 trace id로 추적이 되어야 합니다.