RESTful API는 HTTP 기반의 웹 서비스 설계 패러다임으로, 자원을 중심으로 데이터를 주고받는 현대 웹 및 모바일 애플리케이션의 핵심 통신 방식입니다.
많은 개발자들이 API를 “그냥 HTTP로 만들어진 것”이라고 생각하지만, REST의 개념과 원칙을 제대로 이해하고 설계하면, 시스템의 확장성, 유지보수성, 보안성이 크게 향상됩니다.
이 글에서는 RESTful API의 기본 개념부터 설계 방법까지 자세히 다루어, 지금까지 잘못 만든 API를 개선하고자 하는 분들께 도움이 되고자 합니다.RESTful API는 현대 웹 및 모바일 애플리케이션의 핵심 통신 방식입니다. 많은 개발자들이 API를 “그냥 HTTP로 만들어진 것”이라고 생각하지만, REST의 개념과 원칙을 제대로 이해하고 설계하면, 시스템의 확장성, 유지보수성, 보안성이 크게 향상됩니다. 이 글에서는 RESTful API의 기본 개념부터 설계 방법까지 자세히 다루어, 지금까지 잘못 만든 API를 개선하고자 하는 분들께 도움이 되고자 합니다.


🔍 RESTful API란?

1. 개념 정의

  • *REST(Representational State Transfer)
    *
    REST는 웹의 아키텍처 스타일 중 하나로, HTTP의 기본 메커니즘(메서드, 상태 코드, 헤더 등)을 활용하여 자원을 표현(Representation)하고 상태를 전이(State Transfer)하는 방법입니다.
  • 자원(Resource) : API가 다루는 대상, 데이터의 단위(예: 사용자, 상품, 주문 등)는 고유한 URI를 통해 식별됩니다.
  • 표현(Representation) : 자원의 상태는 JSON, XML 등으로 표현됩니다.

2. REST의 6가지 제약 조건

RESTful API를 설계할 때 지켜야 하는 핵심 제약 조건은 다음과 같습니다:

  1. 클라이언트-서버 :
    클라이언트와 서버의 역할을 명확히 분리하여, 클라이언트는 UI/UX에, 서버는 데이터와 비즈니스 로직에 집중합니다.
  2. 무상태(Stateless) :
    각 요청은 독립적이어야 하며, 서버는 이전 요청의 상태를 저장하지 않습니다. 필요한 모든 정보는 요청에 포함되어야 합니다.
  3. 캐시 가능(Cacheable) :
    응답은 캐시 가능해야 하며, 적절한 캐시 헤더를 통해 성능을 최적화할 수 있습니다.
  4. 일관된 인터페이스(Uniform Interface) :
    API의 모든 상호작용은 일관된 방식으로 진행되어야 합니다. 이를 위해 URI는 명사 형태, HTTP 메서드(GET, POST, PUT, DELETE)를 사용합니다.
  5. 계층화 시스템(Layered System) :
    클라이언트는 서버의 내부 구현(프록시, 게이트웨이 등)을 알 필요 없이 API와 상호작용할 수 있어야 합니다.
  6. 코드 온디맨드(Code on Demand) – 선택 사항 :
    서버가 클라이언트에 실행 가능한 코드를 전송할 수 있으나, 일반적으로는 사용하지 않습니다.

🔍 RESTful API 설계 방법 및 규칙

1. ⭐ 자원 중심 설계 (Resource-Oriented Design) ⭐

  • URI 설계 : 자원을 식별하는 URI는 명사 형태로 구성합니다.
    • 예) /users (전체 사용자), /users/{userId} (특정 사용자)
  • CRUD 작업: HTTP 메서드를 사용해 자원에 대한 작업을 표현합니다.
    • GET /users : 사용자 조회
    • POST /users : 사용자 생성
    • PUT /users/{userId} : 사용자 전체 업데이트
    • PATCH /users/{userId} : 사용자 일부 업데이트
    • DELETE /users/{userId} : 사용자 삭제

2. ⭐ HTTP 메소드 사용 용도 ⭐

HTTP
메서드
용도 설명 멱등성
(Idempotence)
GET 조회 리소스(데이터)를 조회하여 클라이언트에게 반환합니다.
요청 시 서버의 상태를 변경하지 않습니다.
보장
POST 생성 새로운 리소스를 생성할 때 사용합니다.
요청 본문에 생성할 데이터(페이로드)를 포함시킵니다.
보장되지 않음
PUT 전체 수정 기존 리소스를 완전히 대체하여 업데이트합니다.
전체 리소스 데이터를 제공해야 하며, 요청을 여러 번 보내도 동일한 결과가 나옵니다.
보장
PATCH 부분 수정 기존 리소스의 일부 속성만 수정합니다.
전체 리소스를 대체하지 않고, 필요한 부분만 업데이트할 때 사용합니다.
보장되지 않음
DELETE 삭제 지정된 리소스를 삭제합니다.
삭제 작업은 리소스를 완전히 제거하는 작업입니다.
보장

3. ⭐ HTTP 상태 코드 활용 ⭐

  • 200 OK : 요청 성공 (데이터 반환)
  • 201 Created : 새로운 자원 생성 성공
  • 204 No Content : 삭제나 업데이트 성공, 응답 본문 없음
  • 400 Bad Request : 클라이언트 요청 오류
  • 401 Unauthorized/403 Forbidden : 인증/권한 문제
  • 404 Not Found : 자원 미발견
  • 500 Internal Server Error : 서버 오류

4. 📌 데이터 포맷 및 버전 관리

  • 데이터 포맷 : 주로 JSON을 사용합니다.
  • API 버전 관리 : URI에 버전 정보를 포함하거나, 헤더를 통해 버전을 관리합니다.
    • 예: /v1/users 또는 Accept: application/vnd.example.v1+json

5. 🔒 보안 고려사항

  • 인증 및 인가 : JWT, OAuth 등 보안 토큰을 사용해 접근을 제어합니다.
  • HTTPS : 모든 통신은 HTTPS를 통해 암호화하여 안전하게 전송합니다.

6. 📝 문서화

  • Swagger/OpenAPI : API 문서를 자동으로 생성하고, 협업 및 외부 개발자와 공유합니다.
  • Postman Collection : 테스트 및 문서화 도구로 활용하여 API 사용법을 쉽게 전달할 수 있습니다.

🔍 RESTful API 설계 예시

예시 : 사용자 관리 API

GET /v1/users
  - 설명 : 모든 사용자 목록 조회
  - 응답 예시: 
    [
      { "id": 1, "name": "Alice", "email": "alice@example.com" },
      { "id": 2, "name": "Bob", "email": "bob@example.com" }
    ]

GET /v1/users/1
  - 설명: ID가 1인 사용자 조회
  - 응답 예시: 
    { "id": 1, "name": "Alice", "email": "alice@example.com" }

POST /v1/users
  - 설명: 새로운 사용자 생성
  - 요청 예시:
    {
      "name": "Charlie",
      "email": "charlie@example.com"
    }
  - 응답: 201 Created, Location 헤더에 새 리소스 URI 포함

PUT /v1/users/1
  - 설명: ID가 1인 사용자의 전체 정보 업데이트
  - 요청 예시:
    {
      "name": "Alice Smith",
      "email": "alice.smith@example.com"
    }
  - 응답: 200 OK

DELETE /v1/users/1
  - 설명: ID가 1인 사용자 삭제
  - 응답: 204 No Content

⚡ RESTful API 설계의 핵심 포인트

  • 자원 중심: 모든 API는 자원(데이터) 관점에서 설계
  • HTTP 메서드 활용: GET, POST, PUT/PATCH, DELETE로 CRUD 구현
  • 상태 코드 및 에러 처리: 클라이언트와 서버 간의 명확한 의사소통
  • 보안과 버전 관리: HTTPS, 인증, 버전 관리로 신뢰성 확보
  • 문서화: Swagger 같은 도구를 활용해 명확한 API 문서 제공

⚡ RESTful API 설계 시 유의사항

  • 일관성 유지 : API 전반에 걸쳐 일관된 URI 구조, 메서드 사용, 상태 코드 활용.
  • 확장성 고려 : 미래에 자원이 늘어나거나, 기능이 확장될 때에도 쉽게 관리할 수 있도록 설계.
  • 에러 핸들링 : 명확한 에러 메시지와 상태 코드를 제공해 클라이언트가 문제를 쉽게 파악할 수 있도록 합니다.
  • 보안 강화 : 인증, 인가, HTTPS 적용 등 보안 측면을 항상 최우선으로 고려.
  • 문서화 필수 : 잘 작성된 API 문서는 개발자와 사용자가 API를 쉽게 이해하고 활용할 수 있도록 돕습니다.

💡 결론

RESTful API는 자원 중심의 인터페이스로 설계함으로써, HTTP의 기본 원칙을 활용해 확장성과 유지보수성, 협업 효율성이 뛰어난 시스템을 만들 수 있습니다.
올바른 URI 설계, HTTP 메서드의 적절한 활용, 명확한 에러 처리 및 보안 강화를 통해 API의 일관성과 신뢰성을 높일 수 있으며, Swagger 같은 도구를 활용해 문서화를 철저히 하는 것이 성공적인 RESTful API 설계의 핵심입니다.

728x90
반응형

1. 테스트 프로세스

테스트 프로세스는 테스트와 관련된 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 모든 구성요소를 엮어주는 역할을 함.

테스트 프로세스 5 단계

  계획/제어 -> 분석/설계 -> 구현/실행 -> 완료/리포팅 -> 마감

테스트 프로세스는 계획/제어, 분석/설계, 구현/실행, 완료/리포팅, 마감 5단계로 구성.

  1. 계획과 제어 :
    테스트 계획 수립은 테스트 목표와 임무를 달성하기 위해 이를 확인하고 필요한 활동을 정의.
    테스트 제어는 계획 대비 실제 신행 상황을 비교하는 지속적인 활동.
  2. 분석과 설계 :
    테스트 분석과 설계는 일반적이고 추상적인 테스트 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환.
  3. 구현과 실행 :
    테스트 구현과 실행은 가장 효율적이고 효과적으로 테스트스를 실행하기 위하여 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시져를 명세화.
  4. 완료 조건과 리포팅 :
    초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가.
  5. 테스트 마감 :
    완료된 테스트에서 발견된 사실 및 수집된 데이터, 경험을 취합하고 축적.

2. TC 작성 절차

  문서 수집 -> TC 작성 -> 내부 검토 -> 커버리지 분석 -> 승인
  1. 참조 문서 수집 :
    테스트 계획서에 명시된 테스트 케이스 작성 지침과 수준을 고려,
    테스트 설계에 필요한 분석 및 설계 문서 수집.
  2. TC 작성 :
    테스트 설계 기법을 이용하여 TC를 작성.
  3. 내부 검토 :
    PM, 아키텍트, 디자이너, 기획자, 개발자, QA 담당자가 작성된 TC의 적정성 검토.
  4. 요구사항 대비 커버리지 분석 :
    TC가 어느 정도 요구사항을 반영하는가에 대한 분석.
    기본적으로 테스트 가능한 요구사항은 모두 TC에 반영되어있는지 확인.
  5. 승인 :
    작성된 TC를 클라이언트(현업), 기획자 및 PM에게 승인을 받음.

3. TC 구성요소

  • 식별 번호 :
    TC의 고유 식별자.
  • 이슈 번호, 제목 :
    제목과 이슈 번호를 기입. (Redmine NO., Jira NO.)
  • 요약 (Description) :
    TC의 목표 등 요약된 정보
  • 사전 조건 (Precondition) :
    테스트 수행에 필요한 조건 및 실행환경. (선행 조건, 전제조건)
  • 종속성 (Dependencies) :
    테스트 요구사항 또는 기타 TC에 대한 의존성 판단.
  • 수행 절차 (Test Step) :
    TC를 수행하기 위한 정확한 단계.
  • 기대 결과 (Expect Result) :
    절차대로 진행 시 테스트 통과 여부를 결정하는 기대 결과.
  • 실제 결과 (Actual Result, PASS / FAIL) :
    테스트 수행 후 실제 결과.
  • 비고 (Remark, Note, Comment) :
    기타 비고 사항을 기입.
  • 그 외 :
    우선순위, 모듈 이름, 테스트 설계자, 설계일, 테스트 수행자, 수행일 등

구성 요소는 조직이나 프로젝트에 따라 변경/추가/삭제 될 수 있다.


4. TC 작성 시 주의 점 및 장/단점

주의점

  • 절차의 누락 :
    테스트 절차를 정확하게 입력하지 않을 경우 테스트 수행의 어려움이 생기는 테이스 발생 가능.
  • 장황한 설명 :
    TC 작성 시 상세하고 충분한 정보를 제공해야 하지만, 너무 많은 단어와 불필요한 설명으로 소통의 오류 유발 가능.
  • 전문 용어의 과다 사용 :
    TC 작성 시, 직군간 소통이 불가능한 전문용어를 과다사용시 테스트 수행에 어려움이 있을 수 있음.
  • 분명하지 않은 PASS/FAIL 기준 :
    테스트 수행 후 테스트 결과가 통과인지 실패인지 예상 결과에 정확히 기입하지 않아 결과 판단에 어려움 유발 가능.

단점

  • TC 작성 시간이 수행 시간보다 오래 걸릴 수 있음.
  • 기능 변화에 따른 TC 변경 :
    기능을 자주 변경한다면 추후 테스트 케이스의 통제에 어려움이 생기게 될 수 있음.
  • 배경 지식 판단의 어려움 :
    TC를 작성하는 사람은 테스트 하는 기능을 잘 알고 있으나, 테스트 수행자는 배경 지식이 없을 경우 테스트 수행 시간이 길어지거나 수행에 어려움이 있을 수 있음.

장점

  • 이력 참조 :
    TC는 어플리케이션 런칭 후에도 사용, 유지보수 팀과 추후 어플리케이션의 버전을 담당자의 테스트 이력 참고가 가능.
  • 테스트 진행 상황 추적 :
    TC를 문서화 하면 수행한 TC의 수, 통과/실패 수, 과업 범위 별 케이스 수, 테스트 커버리지 등의 정보를 추적/확인 가능.
  • 반복성 :
    잘 작성된 TC는 누구나 반복적으로 수행 가능.

5. TC 정렬

TC의 정렬은 업부의 효율과 연결될 수 있다. 테스트의 흐름, 테스트 환경 등을 고려해서 정렬 하도록 하자.

흐름이 이어지는 TC 정렬

정렬 전 스펙 문서에 따라 쓴 TC 정렬 후 흐름에 맞춘 TC
1. A 기능 1 실행 1. A 기능 1 실행
2. A 기능 2 실행 2. A 기능 1의 추가기능 실행
3. A 기능 3 실행 3. 기능 2 실행
4. A 기능 1의 추가기능 실행 4. A 기능 2의 추가기능 실행
5. A 기능 2의 추가기능 실행 5. 기능 3 실행
6. A 기능 3의 추가기능 실행 6. A 기능 3의 추가기능 실행

환경이 비슷한 TC 정렬

정렬 전 스펙 문서에 따라 쓴 TC 정렬 후 흐름에 맞춘 TC
1. 기능 A를 관리자(Root) 계정으로 테스트 1. 기능 A를 관리자(Root) 계정으로 테스트
2. 기능 A를 사용자(User) 계정으로 테스트 2. 기능 B를 관리자(Root) 계정으로 테스트
3. 기능 B를 관리자(Root) 계정으로 테스트 3. 기능 C를 관리자(Root) 계정으로 테스트
4. 기능 B를 사용자(User) 계정으로 테스트 4. 기능 A를 사용자(User) 계정으로 테스트
5. 기능 C를 관리자(Root) 계정으로 테스트 5. 기능 B를 사용자(User) 계정으로 테스트
6. 기능 C를 사용자(User) 계정으로 테스트 6. 기능 C를 사용자(User) 계정으로 테스트


TC-template-20240510.xlsx
0.02MB

728x90
반응형

+ Recent posts