[ 👉 API 설계 및 통신 스터디]

👉 API 설계 및 통신

의도 : API 설계와 통신 카테고리는 RESTful API, GraphQL 등의통신 방식에 대한 이해를 평가합니다. API 버전 관리는 서비스의 유지보수성, 확장성을 높이는 중요한 요소모이며, OAuth 2.0과 같은 인증 방식은보안에 대한 기본적인 이해를 평가하는 질문입니다. API의 상태 코드, 멱등성(Idempotency)등의 개념도 실무에서 자주 다뤄지는 주제입니다.

답변에 포함해야할 키워드

• RESTful API : HTTP 메서드(GET, POST, PUT, DELETE)의 활용
• GraphQL : 클라이언트가 원하는 데이터만 요청할 수 있는 API 방식
• OAuth 2.0 : 사용자 인증과 권한 부여를 위한 프로토콜
• 멱등성(Idmpotency) : 동일한 요청을 여러 번 보내도 결과가 동일한지 여부
• HTTP 상태 코드 : 200(성공), 404(페이지 없음), 500(서버 오류) 등의 의미

⭐ RESTful API는 REST의 원칙을 따르는 API를 의미한다. 자원을 URL(엔드포인트)로 표현하고 HTTP 메서드를 활용해 자원을 주고 받는 방식이다.

⭐ SOAP 소프(Simple Object Access Protocol)은 XML 기반의 메시지 프로토콜로, 네트워크 상에서 데이터를 주고받는 표준 방식 중 하나로 보안, 트랜잭션, 메시지 신뢰성을 중요하게 여기는 환경에서 주로 사용된다.

⭐ GraphQL은 Facebook에서 개발한 API 쿼리 언어로, 클라이언트가 원하는 데이터만 정확하게 요청하고 받을 수 있도록 설계된 방식이다. REST API처럼 여러 개의 엔드포인트를 두는 것이 아니라, 단일 엔드포인트에서 요청(Query)마다 필요한 데이터 구조를 정의할 수 있다.

1. [하] RESTful API의 설계 원칙을 설명해주세요.

RESTful API의 설계 원칙은 리소스 기반 설계를 따르며, 주요 원칙은
클라이언트-서버 구조 : 클라이언트와 서버의 역할을 명확히 분리
무상태성(Stateless) : 요청 간의 상태 정보를 유지하지 않음
캐시 가능 : 응답을 캐싱하여 성능 최적화
계층화된 시스템 : 여러 계층을 통해 구조화 가능
일관된 인터페이스 : HTTP 메서드를 활용한 리소스 조작

RESTful API는 클라이언트와 서버를 분리하고 HTTP 메서드(GET,POST,PUT,DELETE)를 활용하여 리소스를 조작하는 구조를 따릅니다. 주요 원칙으로는 무상태성, 캐싱, 계층화, 일관된 인터페이스, 자체 표현 등이 있습니다. 특히 무상태성을 유지하면 서버 확장성이 좋아지고, 캐싱을 통해 네트워크 성능을 최적화할 수 있습니다.

2. [중] REST와 SOAP의 차이점을 설명해 주세요.

프로토콜 : REST는 HTTP 기반, SOAP는 XML 기반의 프로토콜
데이터 형식 : REST는 JSON, XML 등 다양한 형식 지원, SOAP는 XML만 사용
속도 및 확장성 : REST가 가볍고 빠르며 확정성이 높음, SOAP는 보안과 트랜잭션 관리에 강점
사용 사례 : REST는 웹 서비스 및 모바일 앱 API, SOAP는 금융-기업 시스템

REST는 경량화된 구조로 JSON, XML 등 다양한 데이터 형식을 지원하며, HTTP 기반으로 동작합니다. 반면 SOAP는 XML 기반의 프로토콜로 보안과 트랜잭션이 중요한 환경에서 사용됩니다. REST는 웹 및 모바일 서비스 개발에 적합하고 SOAP는 금융, 엔터프라이즈 시스템 등 신뢰성이 요구되는 환경에서 주로 활용됩니다.

3. [중] API 버전 관리의 중요성과 방법을 설명해 주세요.

API는 한 번 배포 되면 여러 클라이어튼가 사용하기 때문에, 기능 변경 시에도 기존 사용자의 영향을 최소화해야합니다. 이를 위해 URL 버전링, 헤더 기반 버전 관리, 쿼리 파라미터 방식 등을 활용할 수 있습니다. 주요 전략으로는 하위 호환성을 유지하면서 점진적으로 개선하는 방식이 필요합니다.

기능추가, 기존 기능 변경, 보안 개선
하휘 호환성을 보존하면서 개선 방식
URL 버전링 (url에 v1, v2를 넣어주는법)
헤더 관리 -> GrahQL을 사용할 때 쓴다.

4. [상] GraphQL과 REST API의 차이점을 설명하고, 실무에서 어떤 상황에 적합한지 이야기해주세요.

REST는 여러 엔드포인트를 통해 정해진 데이터를 방환하는 방식이며, GraphQL은 단일 엔드포인트에서 클라이언트가 필요한 데이터만 요청할 수 있습니다. REST는 캐싱이 용이하고 단순한 CRUD API에 적합하며, GraphQL은 관계형 데이터를 한 번의 요청으로 가져올 때 강점이 있습니다. 데이터 요구 사항이 자주 변경되는 프로젝트라면 GraphQL, 표준적인 API 설계가 필요한 경우는 REST를 선택하는 것이 적절합니다.

데이터 요청 방식에서 처리,
REST는 불필요한 데이터(오버패칭)까지 끌고오는데 GraphQL은 원하는 데이터만 가져올 수 있는 장점
(언더패칭) : 5개를 가져와야되는데 2개만 가져왔을 때, 추가로 3개를 가져와야되는 경우를 언더패칭

5. [중] OAuth 2.0이 무엇이며, 이를 사용한 인증 방식에 대해 설명해주세요.

OAuth 2.0은 토큰 기반 인증 방식으로 클라이언트가 사용자 인증 없이 리소스에 접근하도록 허용하는 것

인가방식 4가지가 있음 인가코드, 암시적 인증 방식

OAuth 2.0은 인증과 권한 위임을 위한 프로토콜로, 사용자 자격 증명을 직접 노출하지 않고 엑세스 토큰을 이용하여 인증을 수행합니다. 대표적인 방식으로 Authorization Code, Implicit, Client Credentials, Resource Owner Password Credentials가 있으며, 일반적으로 보안성 높은 Authorzation COde 방식을 많이 사용합니다.

6. [중] HTTP 상태 코드 중 200, 404, 500의 차이와 각각의 의미를 설명해주세요.

200 OK : 요청이 정상적으로 처리됨, 404 Not Found : 요청한 리소스를 찾을 수 없음, 500 Internal Server Error : 서버 내부에서 예기치 않은 오류 발생

7. [상] 멱등성(Idempotency)이란 무엇이며, API 설계 시 이를 어떻게 고려할 수 있는지 설명해주세요.

멱등성 : 같은 요청을 여러번 보내도 결과가 변하지 않는 속성

멱등성이란 동일한 요청을 여러 번 수행해도 동일한 결과를 보장하는 성질을 의미합니다. 예를 들어 GET/user/1은 항상 동일한 데이터를 반환해야 하며, PUT/user/1{name:"John"}도 동일한 요청을 여러번 보내도 결과가 변경되지 않아야 합니다. 반면, POST 요청은 새로운 리소스를 생성하는 것이므로 멱등성을 보장하지 않습니다.

8. [중] API 문서를 자동으로 생성하는 방법(Spring REST Docs 등)에 대해 설명해주세요.

API 문서는 개발자 간의 원활한 협업과 유지보수를 위해 필수적이며, 이를 자동화하는 방법으로는 Swagger, Spring REST Docs, Redoc등이 있습니다.
스웨거 : UI 기반의 API 테스트 및 문서화 제공
Spring REST Docs : 코드 기반 문서화, 마크다운 지원
Redos : 오픈API 문서를 정리하여 가독성을높은 문서 제공

9. [상] HATEOAS(Hypermedia as the Engine of Application State)란 무엇이며, RESTful API에 어떻게 적용할 수 있는지 설명해 주세요.

HATEOAS는 쉽게 말하면 API 응답에 "다음에 뭘 하면 좋을지"를 알려주는 링크를 같이 포함하는 방식입니다. 예를들어 상품 정보를 요청하면 상품 데이터와 함계 관련된 카테고리나 리뷰 페이지로 이동할 수있는 링크도 포함해서 보내주는 것이죠. 이렇게 하면 클라이언트는 별도 로 API 문서를 찾아볼 필요 없이 응답을 보고 필요한 데이터를 탐색할 수 잇습니다. 유지보수도 쉬어지고 API 확장에도 유리한 구조가 됩니다.

RESTful API 전송할때 HATEOAS 방식으로 GET,POST 등 URL 정보를 서버에서 전송한다.
서버가 제공하는 하이퍼미디어 링트를 통해 상태를 제공하는 방식
클라리언트는 API가 제공하는 링크와 키워드 기반으로 리소스를 탐색하고 상태 전환
URL 변경 의존도 ⬇️

10. [상] HTTP/2와 HTTP/1.1의 차이점을 설명해 주세요.

멀티 플렉싱 : HTTP/2는 하나의 TCP 연결에서 여러 요청을 동시에 처리 가능
헤더 압축 : HPACK을 사용하여 헤더 크기를 줄여 네트워크 효율 개선
서버 푸시 : 클라이언트가 요청하기 전에 필요한 리소스를 미리 전송 가능
속도 개선 : HTTP/1.1 대비 지연 시간이 줄어들고 성능이 향상됨
실무에서는 성능 최적화를 위해 HTTP/2를 적용하는 것이 일반적이며, 특히 대용량 데이터를 다루는 환경에서 더욱 유용합니다.

HTTP/1.1에서는 요청을 한 개씩 순차적으로 처리해야 해서 속도가 느릴 수 있는데, HTTP/2는 하나의 연결로 여러 개의 요청을 동시에 보낼 수 있습니다.(멀티플렉싱). 또, 헤더를 압축해서 네트워크 트래픽을 줄이고, 서버가 클라이언트 요청 전에 필요한 데이터를 미리 보내줄 수도 있다.(서버푸시), 그래서 HTTP/2를 적용하면 웹사이트 로딩 속도가 빨라지고 성능이 확실히 좋아진다.

1.1은 하나의 연결에서 여러 요청을 처리하여 HOLB가 발생
이후 문제발생시, 후속 요청들이 전송되지 못하고 지연되는 문제 발생
위 문제를 해결하기 위해 병렬처리 도입을 위한 2가 나옴
하나의 연결로 여러 스트림을 메시지를 담아 전달 (바이너리 인코딩)