세션5. API 설계

1. 첫 번째 API(Application Programming Interface) 설계

우리가 만들고자 하는 서비스 아키텍처는 다음과 같다. (우리는 전자 상거래 플랫폼 API 만 담당한다)

첫 번째 API

• 판매자 회원 가입 기능을 제공한다.

• 판매자는 이메일 주소, 사용자이름, 비밀번호를 사용해 가입한다.

판매자 회원 가입 정책

• 이메일 주소는 유일해야 한다.

• 사용자이름은 유일해야 한다.

• 사용자이름은 3자 이상의 영문자, 숫자, 하이픈, 밑줄 문자로 구성되어야 한다.

• 비밀번호는 8자 이상의 문자로 구성되어야 한다.

판매자 회원 가입 API 테스트 시나리오 목록

• 올바르게 요청하면 204 No Content 상태코드를 반환한다.

• email 속성이 지정되지 않으면 400 Bad Request 상태코드를 반환한다.

• email 속성이 올바른 형식을 따르지 않으면 400 Bad Request 상태코드를 반환한다.

• username 속성이 지정되지 않으면 400 Bad Request 상태코드를 반환한다.

• username 속성이 올바른 형식을 따르지 않으면 400 Bad Request 상태코드를 반환한다.

• password 속성이 지정되지 않으면 400 Bad Request 상태코드를 반환한다.

• password 속성이 올바른 형식을 따르지 않으면 400 Bad Request 상태코드를 반환한다.

• email 속성에 이미 존재하는 이메일 주소가 지정되면 400 Bad Request 상태코드를 반환한다.

• username 속성에 이미 존재하는 사용자이름이 지정되면 400 Bad Request 상태코드를 반환한다.

• 비밀번호를 올바르게 암호화한다.

2. API 설계 문서화

# 스프링 부트 TDD - 입문부터 실전까지 정확하게

"스프링 부트 TDD - 입문부터 실전까지 정확하게" 인프런 강의의 실습 코드 저장소입니다.

## 응용프로그램 빌드

```bash
./gradlew build
```

## 응용프로그램 실행

```bash
./gradlew bootRun
```

## API 목록

### 판매자 회원 가입

요청
- 메서드: POST
- 경로: /seller/signUp
- 헤더
  ```
  Content-Type: application/json
  ```
- 본문
  ```
  CreateSellerCommand {
    email: string,
    username: string,
    password: string
  }
  ```

성공 응답
- 상태코드: 204 No Content

정책
- 이메일 주소는 유일해야 한다
- 사용자이름은 유일해야 한다
- 사용자이름은 3자 이상의 영문자, 숫자, 하이픈, 밑줄 문자로 구성되어야 한다
- 비밀번호는 8자 이상의 문자로 구성되어야 한다

테스트
- [ ] 올바르게 요청하면 204 No Content 상태코드를 반환한다
- [ ] email 속성이 지정되지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] email 속성이 올바른 형식을 따르지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] username 속성이 지정되지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] username 속성이 올바른 형식을 따르지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] password 속성이 지정되지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] password 속성이 올바른 형식을 따르지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] email 속성에 이미 존재하는 이메일 주소가 지정되면 400 Bad Request 상태코드를 반환한다
- [ ] username 속성에 이미 존재하는 사용자이름이 지정되면 400 Bad Request 상태코드를 반환한다
- [ ] 비밀번호를 올바르게 암호화한다

3. 수동 API 실행 명령

# 스프링 부트 TDD - 입문부터 실전까지 정확하게

"스프링 부트 TDD - 입문부터 실전까지 정확하게" 인프런 강의의 실습 코드 저장소입니다.

## 응용프로그램 빌드

```bash
./gradlew build
```

## 응용프로그램 실행

```bash
./gradlew bootRun
```

## API 목록

### 판매자 회원 가입

요청
- 메서드: POST
- 경로: /seller/signUp
- 헤더
  ```
  Content-Type: application/json
  ```
- 본문
  ```
  CreateSellerCommand {
    email: string,
    username: string,
    password: string
  }
  ```
- curl 명령 예시
  ```bash
  curl -i -X POST 'http://localhost:8080/seller/signUp' \
  -H 'Content-Type: application/json' \
  -d '{
    "email": "[e-mail]",
    "username": "seller1",
    "password": "seller1-password"
  }'
  ```

성공 응답
- 상태코드: 204 No Content

정책
- 이메일 주소는 유일해야 한다
- 사용자이름은 유일해야 한다
- 사용자이름은 3자 이상의 영문자, 숫자, 하이픈, 밑줄 문자로 구성되어야 한다
- 비밀번호는 8자 이상의 문자로 구성되어야 한다

테스트
- [ ] 올바르게 요청하면 204 No Content 상태코드를 반환한다
- [ ] email 속성이 지정되지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] email 속성이 올바른 형식을 따르지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] username 속성이 지정되지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] username 속성이 올바른 형식을 따르지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] password 속성이 지정되지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] password 속성이 올바른 형식을 따르지 않으면 400 Bad Request 상태코드를 반환한다
- [ ] email 속성에 이미 존재하는 이메일 주소가 지정되면 400 Bad Request 상태코드를 반환한다
- [ ] username 속성에 이미 존재하는 사용자이름이 지정되면 400 Bad Request 상태코드를 반환한다
- [ ] 비밀번호를 올바르게 암호화한다

4. 정리

• 여기서 중요한 시사점은 아직 코드는 한줄도 적지 않았다는 것이다.

• API 관련 문서화 & HTTP 인터페이스에 대한 설계를 진행했다.

• 여기서 작성한 테스트 시나리오를 기반으로 테스트 코드를 만들고 + 실제 서비스 코드를 만들 것이다.

• 때문에, 가장 처음 프로세스인 테스트 시나리오의 단단함의 시스템 결과의 단단함과 직결된다고 볼 수 있다.