[Sprint 성취도 평가] RESTful APIs 구현하기 이론평가
문제1. API의 핵심 특성인 ‘추상화’와 ‘캡슐화’가 어떻게 코드의 재사용성과 구현 은닉을 가능하게 하는지 구체적인 예시와 함께 설명하세요.
[SB] [RESTful API 구현하기]
문제1-1. 답변
API만 가져다 사용하면 어떻게 구현되었는지 상관없이 API에 구현된 기능들을 사용할 수 있고, 동일하게 반복되는 기능을 여러 곳에 구현하지 않고 API로 만들면 한 곳에 구현하고 여러 곳에서 재사용 가능
문제 1-2. 정리
추상화는 복잡한 내부 로직을 단순한 인터페이스로 제공하는 것이며, 캡슐화는 구현 세부사항을 숨기고 필요한 기능만 노출하는 것입니다. 예를 들어, 데이터베이스 API는 복잡한 쿼리 처리와 연결 관리를 추상화하여 단순한 메서드로 제공하고, 내부 구현을 캡슐화하여 보안과 안정성을 보장합니다.
코드 재사용성 측면에서 API는 검증된 기능을 여러 애플리케이션에서 반복적으로 사용할 수 있게 해줍니다. 예를 들어, 결제 API를 사용하면 보안적으로 검증된 결제 처리 로직을 재사용할 수 있습니다.
구현 은닉을 통해 API 사용자는 내부 구현의 복잡성을 이해할 필요 없이 문서화된 인터페이스만으로 기능을 활용할 수 있습니다. 또한 API 제공자는 내부 구현을 자유롭게 개선하고 업데이트할 수 있습니다.
실제 예시로, Java의 ArrayList 컬렉션은 배열 조작의 복잡한 처리를 추상화하여 add(), remove() 같은 단순한 메서드로 제공하고, 내부의 배열 크기 조정이나 메모리 관리 등을 캡슐화하여 개발자가 쉽게 데이터를 관리할 수 있게 합니다. 개발자는 배열의 동적 확장이나 요소 이동 같은 저수준 로직을 신경 쓸 필요 없이, 간단한 메서드 호출만으로 데이터를 처리할 수 있습니다.
문제 1-3. 채점 코멘트
| ✔️ 추상화와 캡슐화의 개념을 정확히 설명 | 0/4점 |
| ✔️ API가 제공하는 코드 재사용성의 이점 설명 | 2/2점 |
| ✔️ 구현 은닉이 가져오는 장점 설명 | 1/2점 |
| ✔️ 실제 API 사용 예시를 들어 설명 | 0/3점 |
✅ 잘한 부분
- API를 한 번 구현해 두면 여러 곳에서 반복적으로 사용할 수 있다는 점을 설명한 부분이 좋았습니다. 동일한 기능을 여러 번 구현하지 않고 API를 통해 재사용할 수 있다는 설명을 통해 코드 재사용성의 개념을 잘 설명하고 있었어요.
- API를 사용하는 쪽에서는 내부 구현을 알 필요 없이 기능을 사용할 수 있다는 설명을 통해 구현 은닉의 개념을 이해하고 있는 점도 좋았습니다.
❗ 아쉬운 부분
- 추상화와 캡슐화의 개념이 명확하게 설명되지 않은 점은 아쉽습니다. 두 개념을 각각 정의한 뒤 API와 연결해서 설명할 수 있어야 합니다.
- 구현 은닉의 장점이 충분히 설명되지 않은 점도 아쉽습니다. 내부 구현이 변경되더라도 외부 코드에는 영향을 주지 않는다는 점까지 포함해서 답변할 수 있어야 합니다.
- 실제 API 사용 예시가 포함되지 않은 점은 아쉽습니다. REST API 형태(GET /users, POST /payments 등)나 코드 예시를 통해 설명할 수 있어야 합니다.
📚 더 공부하면 좋은 내용
- 추상화와 캡슐화의 객체지향 개념을 먼저 정리해보세요. 추상화는 복잡한 내부 로직을 숨기고 핵심 기능만 인터페이스로 제공하는 개념이고, 캡슐화는 데이터와 로직을 객체 내부에 묶고 외부에서 직접 접근하지 못하도록 보호하는 개념입니다.
- RESTful API 구조를 학습해보세요. 예를 들어 클라이언트가 GET /users/{id} 요청을 보내면 Controller가 요청을 받고 Service를 호출하고 Repository를 통해 데이터를 조회하는 구조를 정리해보세요. 클라이언트는 이러한 내부 로직을 전혀 알 필요가 없습니다.
- 인터페이스 기반 설계를 학습해보세요. 예를 들어 PaymentService 인터페이스를 정의하고 CardPaymentService, KakaoPaymentService 같은 구현체를 만들어 사용하는 구조를 정리해보세요. 실제 코드 예시와 함께 설명하는 연습을 해보면 좋겠습니다. 예를 들어 Controller → Service → Repository 계층 구조를 직접 작성하고 API 호출 흐름을 정리해보면 좋겠습니다.
문제2. REST의 등장 배경과 주요 제약조건을 Richardson 성숙도 모델과 연관지어 설명하세요.
[SB] [RESTful API 구현하기]
문제 2-1. 답변
REST 등장 전에는
- 상태를 세션에 저장
- 요청할 때마다 새로운 프로세스를 생성
- 클라이언트와 서버의 역할 분리가 희미함
REST 제약 조건
- 클라이언트와 서버의 역할을 명확하게 분리
- stateless
- 일관된 접근 방식
- Richardson 성숙도 모델로 REST 준수 정도 파악
- 0 단계 : HTTP 사용
- 1 단계 : URI 사용
- 2 단계 : HTTP 메서드 사용
- 3 단계 : HATAS 사용
- Richardson 성숙도 모델로 REST 준수 정도 파악
- 계층형 아키텍처
문제 2-2. 정리
REST는 웹의 확장성 문제를 해결하기 위해 Roy Fielding이 제안한 아키텍처 스타일입니다. HTTP와 웹의 성공 요인을 분석하여 핵심 원칙들을 도출했습니다.
REST의 주요 제약조건은 다음과 같습니다:
- Client-Server: 관심사의 분리를 통해 클라이언트와 서버가 독립적으로 진화할 수 있습니다.
- Stateless: 각 요청은 이전 요청과 무관하게 독립적으로 처리되어 확장성을 확보합니다.
- Cache: 응답의 캐시 가능 여부를 명시하여 효율성을 향상시킵니다.
- Uniform Interface: 리소스에 대한 일관된 인터페이스를 제공하여 전체 시스템 아키텍처를 단순화합니다.
- Layered System: 계층화된 시스템을 구성하여 확장성과 보안성을 높입니다.
Richardson 성숙도 모델은 REST 적용 수준을 4단계로 구분합니다:
- Level 0: HTTP를 단순한 전송 수단으로만 사용
- Level 1: 개별 리소스 개념 도입
- Level 2: HTTP 메서드를 의미에 맞게 사용
- Level 3: HATEOAS 적용으로 자기 서술적 메시지 구현
실제 적용 시에는 모든 제약조건을 완벽히 만족시키기 어려우므로, 시스템의 요구사항과 제약사항을 고려한 실용적인 판단이 필요합니다. 특히 HATEOAS의 경우, 구현 복잡도와 이점을 비교하여 적용 수준을 결정해야 합니다.
문제 2-3. 채점 코멘트
| ✔️ REST의 탄생 배경과 Roy Fielding의 문제 의식 설명 | 1/2점 |
| ✔️ REST의 주요 제약조건 5가지와 각각의 의미 설명 | 2/4점 |
| ✔️ Richardson 성숙도 모델의 각 단계별 특징 설명 | 1/2점 |
| ✔️ 현실에서의 REST 적용 시 고려해야 할 트레이드오프 설명 | 0/2점 |
✅ 잘한 부분
- REST 등장 이전의 구조를 설명하면서 상태를 세션에 저장하거나 클라이언트와 서버의 역할 분리가 명확하지 않았다는 점을 언급한 부분이 좋았습니다. 기존 구조의 문제를 바탕으로 REST의 필요성을 설명하고 있어요.
- 또한 REST 제약조건 중 Client-Server 구조와 Stateless를 언급하며 서버와 클라이언트의 역할을 분리하고 상태를 저장하지 않는 구조를 설명한 점도 좋았습니다. 이는 REST의 핵심적인 설계 원칙을 잘 이해하고 있는것을 확인할 수 있었어요.
- Richardson 성숙도 모델을 통해 REST 준수 정도를 파악한다는 설명과 함께 0단계부터 3단계까지의 구조를 간단하게 정리한 점도 좋았습니다.
❗ 아쉬운 부분
- REST의 등장 배경에서 Roy Fielding의 문제 의식이 설명되지 않은 점은 아쉽습니다. REST는 Roy Fielding이 웹의 확장성과 단순성을 유지하기 위해 HTTP와 웹 아키텍처의 특징을 분석하여 제안한 아키텍처 스타일이라는 내용을 포함해서 답변할 수 있어야 합니다.
- REST의 주요 제약조건이 모두 설명되지 않은 점도 아쉽습니다. 문제에서는 Client-Server, Stateless, Cache, Uniform Interface, Layered System 다섯 가지 제약조건과 각각의 의미를 설명해야 합니다. 현재 답변에서는 Cache 제약조건이 빠져 있고 각 제약조건의 의미 설명도 충분하지 않은 점이 아쉽습니다.
- Richardson 성숙도 모델의 단계 설명이 조금 간단한 점도 아쉽습니다. Level 0이 HTTP를 단순 전송 수단으로 사용하는 단계라는 점, Level 1이 리소스 중심 URI 설계라는 점, Level 2가 HTTP 메서드를 의미에 맞게 사용하는 단계라는 점 등을 조금 더 구체적으로 설명할 수 있어야 합니다.
- 현실적인 REST 적용 시의 트레이드오프가 설명되지 않은 점도 아쉽습니다. 실제 서비스에서는 구현 복잡도 때문에 HATEOAS까지 적용하지 않고 Level 2 수준까지만 적용하는 경우가 많다는 설명 등을 포함해서 답변할 수 있어야 합니다.
📚 더 공부하면 좋은 내용
- REST의 등장 배경을 정리해보세요. REST는 Roy Fielding이 자신의 박사 논문에서 웹이 대규모로 확장되는 환경에서도 안정적으로 동작하도록 하기 위해 제안한 아키텍처 스타일입니다. HTTP와 웹의 성공 요인을 분석하고 이를 기반으로 REST 설계 원칙을 정리했습니다.
- REST의 주요 제약조건도 정리해보세요. Client-Server는 역할 분리를 의미하고 Stateless는 서버가 상태를 저장하지 않는 구조입니다. Cache는 응답 재사용을 통해 성능을 개선합니다. Uniform Interface는 리소스 중심의 일관된 인터페이스를 의미합니다. Layered System은 여러 계층을 통해 요청이 처리되는 구조입니다.
- Richardson 성숙도 모델도 단계별로 정리해보세요. Level 0은 HTTP를 단순 전송 수단으로 사용하는 단계입니다. Level 1은 리소스를 URI로 구분하는 단계입니다. Level 2는 HTTP 메서드를 의미에 맞게 사용하는 단계입니다. Level 3은 HATEOAS를 적용하는 단계입니다.
- 실제 REST 설계에서는 구현 복잡도를 고려하여 Richardson Level 2 수준까지만 적용하는 경우가 많다는 점도 함께 학습해보면 좋겠습니다.
문제3. RESTful API에서 HTTP 메서드의 의미와 상태 코드의 활용 방안에 대해 구체적인 예시와 함께 설명하세요.
[SB] [RESTful API 구현하기]
문제 3-1. 답변
HTTP 메서드
- GET : 조회
- POST : 생성
- PUT : 덮어쓰기
- PATCH : 일부 수정
- DELETE : 삭제
상태코드 적용 시점
- 2xx : 성공
- 3xx : 리다이렉션
- 4xx : 클라이언트 오류
- 5xx : 서버 오류
문제 3-2. 정리
RESTful API에서 HTTP 메서드는 리소스에 대한 작업을 나타냅니다:
- GET: 리소스 조회, 안전한(safe) 작업, 멱등성 보장
- POST: 새로운 리소스 생성, 상태 변경 작업
- PUT: 리소스 전체 수정, 멱등성 보장
- PATCH: 리소스 부분 수정
- DELETE: 리소스 삭제, 멱등성 보장
HTTP 상태 코드는 요청의 처리 결과를 나타냅니다:
- 2xx: 성공 (200 OK, 201 Created, 204 No Content)
- 4xx: 클라이언트 오류 (400 Bad Request, 401 Unauthorized, 404 Not Found)
- 5xx: 서버 오류 (500 Internal Server Error, 503 Service Unavailable)
예를 들어, 사용자 리소스에 대한 API는 다음과 같이 설계할 수 있습니다:
- GET /users/123 → 200 OK (조회 성공)
- POST /users → 201 Created (생성 성공)
- PUT /users/123 → 200 OK (수정 성공)
- DELETE /users/123 → 204 No Content (삭제 성공)
에러 처리 시에는 상황에 맞는 상태 코드와 함께 상세한 에러 정보를 제공해야 합니다.
문제 3-3. 채점 코멘트
| ✔️ 주요 HTTP 메서드(GET, POST, PUT/PATCH, DELETE)의 의미와 용도 설명 | 2/3점 |
| ✔️ 주요 상태 코드 그룹(2xx, 4xx, 5xx)의 의미와 대표적인 상태 코드 설명 | 1/3점 |
| ✔️ 실제 API 예시를 통한 메서드와 상태 코드의 적절한 조합 설명 | 0/2점 |
| ✔️ 에러 상황에서의 적절한 상태 코드 선택과 응답 구조 설명 | 1/2점 |
✅ 잘한 부분
- HTTP 메서드의 기본적인 역할을 간단하게 정리한 점이 좋았습니다. GET은 조회, POST는 생성, PUT은 덮어쓰기, PATCH는 일부 수정, DELETE는 삭제라는 형태로 주요 메서드의 역할을 구분하여 정리한 점이 좋았습니다.
- REST API에서 메서드는 리소스에 대한 행위를 표현한다는 점을 잘 이해하고 있어요.
- 또한 상태 코드의 범위를 2xx, 3xx, 4xx, 5xx로 구분하여 설명한 점도 좋았습니다. 2xx는 성공, 3xx는 리다이렉션, 4xx는 클라이언트 오류, 5xx는 서버 오류라는 구조를 정리한 점을 통해 상태 코드가 요청 결과의 범주를 표현한다는 점을 명확히 설명하고 있어요.
❗ 아쉬운 부분
- 상태 코드 설명에서 대표적인 상태 코드 예시가 포함되지 않은 점이 조금 아쉬웠어요. 예를 들어 200 OK, 201 Created, 204 No Content, 400 Bad Request, 404 Not Found, 500 Internal Server Error와 같은 대표적인 상태 코드를 함께 설명할 수 있어야 합니다.
- 또한 실제 API 예시가 전혀 포함되지 않은 점이 아쉽습니다. 예를 들어 GET /users/1 → 200 OK, POST /users → 201 Created, DELETE /users/1 → 204 No Content와 같이 HTTP 메서드와 상태 코드가 함께 사용되는 구체적인 API 요청 예시를 포함해서 답변할 수 있어야 합니다.
- 에러 상황에서 어떤 상태 코드를 선택해야 하는지에 대한 설명도 부족한 점이 아쉽습니다. 예를 들어 요청 데이터가 잘못된 경우 400 Bad Request, 존재하지 않는 리소스 요청 시 404 Not Found, 서버 내부 오류 발생 시 500 Internal Server Error와 같이 상황에 따른 상태 코드 선택을 설명할 수 있어야 합니다.
📚 더 공부하면 좋은 내용
- RESTful API에서 사용하는 주요 HTTP 메서드의 특징을 조금 더 정리해보세요. GET은 리소스 조회, POST는 리소스 생성, PUT은 리소스 전체 수정, PATCH는 리소스 부분 수정, DELETE는 리소스 삭제를 의미합니다. 이러한 메서드의 역할을 함께 학습해보세요.
- HTTP 상태 코드의 대표적인 예시도 함께 정리해보세요. 200 OK는 조회 성공, 201 Created는 리소스 생성 성공, 204 No Content는 삭제 성공에 사용됩니다. 또한 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error와 같은 상태 코드도 함께 학습해보세요.
- REST API 설계에서는 HTTP 메서드와 상태 코드를 함께 사용하여 API의 의미를 표현합니다. 예를 들어 GET /users/1 → 200 OK, POST /users → 201 Created, PUT /users/1 → 200 OK, DELETE /users/1 → 204 No Content와 같은 구조를 정리해보면 좋겠습니다.
문제4. Spring 기반의 RESTful API에서 다양한 요청을 처리하는 방식과 각 요청 처리 어노테이션(@PathVariable, @RequestParam, @RequestBody)의 활용 방안에 대해 설명하세요.
[SB] [RESTful API 구현하기]
문제 4-1. 답변
@PathVariable: URI 경로 내에 있는 변수를 받아오는 애너테이션@RequestParam: 쿼리 파라미터를 받아오는 애너테이션@RequestBody: HTTP Body를 받아서 객체로 변환하는 애너테이션@RequestPart: MULTI PART FORM DATA(image + json 등)를 받아오는 애너테이션
문제 4-2. 정리
Spring의 요청 처리 어노테이션은 각각 다음과 같은 용도로 사용됩니다:
- @PathVariable: URI 경로에 포함된 변수를 추출합니다. RESTful 리소스를 식별하는 데 주로 사용됩니다. 필수 값이며, 경로의 일부이므로 생략할 수 없습니다.
- @RequestParam: 쿼리 스트링 파라미터를 처리합니다. 선택적 데이터나 필터링, 정렬, 페이징 등의 부가적인 요청 정보를 받을 때 사용됩니다.
- @RequestBody: HTTP 요청 본문을 객체로 변환합니다. JSON 형태의 복잡한 데이터를 전송할 때 사용됩니다.
URI 설계 시에는 다음 기준으로 어노테이션을 선택합니다:
- 리소스를 식별하는 고유한 값은 경로 변수로 처리하여 @PathVariable을 사용합니다.
- 검색, 필터링, 정렬과 같은 부가적인 조건은 쿼리 파라미터로 처리하여 @RequestParam을 사용합니다.
- 리소스 생성이나 수정을 위한 복잡한 데이터는 요청 본문으로 처리하여 @RequestBody를 사용합니다.
요청 처리 어노테이션 활용 시 다음 사항들을 고려해야 합니다:
- @PathVariable은 필수 값이므로 클라이언트가 반드시 제공해야 하는 식별자에 사용합니다.
- @RequestParam은 선택적 파라미터 처리가 가능하며, 기본값 설정을 통해 누락된 파라미터에 대한 처리가 가능합니다.
- @RequestBody는 HTTP 메시지 컨버터를 통해 자동으로 객체 변환이 이루어지므로, 요청 본문의 데이터 구조와 일치하는 객체를 준비해야 합니다.
문제 4-3. 채점 코멘트
| ✔️ 각 요청 처리 어노테이션의 용도와 특징 설명 | 3/4점 |
| ✔️ URI 설계에 따른 적절한 어노테이션 선택 기준 설명 | 1/3점 |
| ✔️ 요청 처리 어노테이션 활용 시 고려사항 설명 | 1/3점 |
✅ 잘한 부분
- @PathVariable, @RequestParam, @RequestBody의 기본적인 역할을 구분하여 정리한 점이 좋았습니다. 각각 URI 경로 변수, 쿼리 파라미터, HTTP 요청 본문 데이터를 처리하는 어노테이션이라는 핵심 개념을 정리한 점이 좋았습니다.
- 또한 추가적으로 @RequestPart를 언급하여 multipart/form-data 요청에서 이미지와 JSON 데이터를 함께 처리할 수 있다는 점을 설명한 부분도 좋았습니다. 실제 API 구현 상황에서 사용할 수 있는 다른 요청 처리 방식까지 함께 언급한 점이 좋았습니다.
❗ 아쉬운 부분
- 각 어노테이션의 특징과 사용 상황에 대한 설명이 매우 간단하여 전체적인 설명이 부족한 점이 조금 아쉬웠어요. 예를 들어 @PathVariable은 리소스를 식별하는 필수 값으로 사용된다는 점을 포함해서 설명할 수 있어야 합니다.
- @RequestParam은 선택적 파라미터 처리와 기본값 설정이 가능하다는 특징도 포함해서 답변할 수 있어야 합니다.
- URI 설계 기준에 대한 설명이 없는 점도 조금 아쉬웠어요. 리소스 식별자는 경로 변수로 처리하고, 검색이나 필터링 조건은 쿼리 파라미터로 처리하며, 생성 및 수정 데이터는 요청 본문으로 처리한다는 기준을 포함해서 설명할 수 있어야 합니다.
- 요청 처리 어노테이션 사용 시 고려해야 할 사항에 대한 설명이 없는 점도 조금 아쉬웠어요.
📚 더 공부하면 좋은 내용
- RESTful API에서 URI 구조에 따라 어떤 어노테이션을 사용하는지 정리해보세요. 리소스 식별자는 @PathVariable을 사용하고, 조회 조건이나 필터링은 @RequestParam을 사용합니다. 리소스 생성 및 수정 데이터는 JSON 형태로 전달되며 @RequestBody를 통해 객체로 변환됩니다.
- 또한 @RequestParam의 required, defaultValue 옵션과 @RequestBody가 HTTP 메시지 컨버터를 통해 객체로 변환되는 과정도 함께 학습해보세요.
문제5. RESTful API에서 리소스 간의 관계를 표현하는 방식을 중첩 리소스와 독립 리소스를 중심으로 각 방식의 장단점과 적절한 사용 시점을 포함해서 설명하세요.
[SB] [RESTful API 구현하기]
문제 5-1. 답변
중첩 리소스는 리소스가 부모-자식 관계이고, 이것을 URI에 표현, GET /api/부모/2/자식으로 작성됨
독립 리소스는 서로 독립적이고, 독립적으로 URI에 표현, GET /api/channel?memberId=2
문제 5-2. 정리
리소스 간 관계는 중첩 리소스와 독립 리소스로 표현할 수 있습니다. 중첩 리소스는 부모-자식 관계를 URI 경로에 직접 표현하며(/users/{id}/orders), 독립 리소스는 각각의 리소스를 독립적으로 표현합니다. 독립 리소스의 경우 기본 URI(/users/{id}, /orders/{id})와 함께 쿼리 파라미터를 활용하여 관계를 표현할 수 있습니다(/orders?userId={id}).
각 방식의 장단점과 적절한 사용 시점은 다음과 같습니다. 중첩 리소스는 관계를 직관적으로 표현할 수 있으나 URI가 복잡해질 수 있어 강한 소유 관계에 적합합니다. 독립 리소스는 단순하고 유연하며, 특히 쿼리 파라미터를 통해 다양한 필터링과 관계 표현이 가능하나 여러 번의 요청이 필요할 수 있어 느슨한 관계에 적합합니다.
리소스 간 관계의 강도에 따라 URI를 설계해야 합니다. 강한 소유 관계나 포함 관계는 중첩으로 표현하고(/teams/{id}/members), 느슨한 관계는 독립적으로 표현하면서 필요에 따라 쿼리 파라미터로 관계를 표현합니다(/articles?authorId={id}). 이를 통해 리소스 간의 관계를 상황에 맞게 표현할 수 있습니다.
요약 정보는 목록 조회나 검색 결과와 같이 다수의 리소스를 다룰 때 사용하고, 상세 정보는 개별 리소스 조회 시 제공합니다. 성능과 사용성을 고려하여 적절한 수준의 정보를 포함해야 하며, 필요한 경우 클라이언트가 추가 요청을 통해 상세 정보를 조회할 수 있도록 설계합니다.
문제 5-3. 채점 코멘트
| ✔️ 중첩 리소스와 독립 리소스의 개념과 차이점 설명 | 2/3점 |
| ✔️ 각 방식의 장단점과 적절한 사용 시점 설명 | 0/2점 |
| ✔️ 리소스 간 관계의 강도에 따른 URI 설계 원칙 설명 | 0/3점 |
| ✔️ 요약 정보와 상세 정보의 구분 기준과 적용 방안 설명 | 0/2점 |
✅ 잘한 부분
- 중첩 리소스를 부모-자식 관계의 리소스를 URI 경로에 표현하는 방식으로 설명한 점이 좋았습니다. URI 구조를 통해 리소스 관계를 표현한다는 핵심 개념을 이해하고 있어요.
- 예시 URI를 함께 작성하여 설명하려는 시도가 보인 점도 좋았습니다. 실제 URI 형태를 통해 개념을 설명하는 예시가 아주 적절했어요.
- 독립 리소스를 쿼리 파라미터를 활용한 URI 구조로 설명하고 있어요. 리소스 관계를 URI 경로가 아니라 파라미터로 표현할 수 있다는 점을 떠올린 점은 좋았습니다.
❗ 아쉬운 부분
- 중첩 리소스와 독립 리소스를 설명할 때 개념과 예시만 작성되어 있고 장점과 단점이 설명되지 않은 점이 아쉽습니다. 예를 들어 중첩 리소스는 관계를 직관적으로 표현할 수 있지만 URI가 길어질 수 있고, 독립 리소스는 URI 구조가 단순하지만 관계 파악이 어려울 수 있다는 점까지 함께 설명할 수 있어야 합니다.
- 리소스 간 관계의 강도에 따라 URI 구조를 선택해야 한다는 설명이 빠져 있습니다. 중첩 리소스는 부모 리소스에 강하게 종속되는 경우에 사용하는 방식이고, 독립 리소스는 리소스가 독립적으로 존재할 수 있는 경우에 사용하는 방식이라는 기준까지 함께 설명할 수 있어야 합니다. 현재 답변에서는 단순히 구조 예시만 작성되어 있어 이 설계 기준을 설명하지 못한 점이 아쉽습니다.
📚 더 공부하면 좋은 내용
- RESTful API에서 중첩 리소스와 독립 리소스의 URI 설계 방식과 각각의 장단점을 함께 정리하여 학습해보세요. /users/{id}/orders 와 /orders?userId={id} 와 같은 구조를 비교하면서 리소스 관계 표현 방식을 학습해보세요. 목록 조회 API와 단일 조회 API에서 응답 데이터의 요약 정보와 상세 정보를 구분하는 설계 방식도 함께 학습해보면 좋겠습니다.
Leave a comment