- RESTful API의 설계 원칙을 설명해주세요
- REST와 SOAP의 차이점을 설명해주세요
- API 버전 관리의 중요성과 방법을 설명해주세요
- GraphQL과 REST API의 차이점을 설명하고, 실무에서 어떤 상황에 적합한지 이야기해주세요
- OAuth 2.0이 무엇이며, 이를 사용한 인증 방식에 대해 설명해주세요
1. RESTful API 설계 원칙
RESTful API의 설계 원칙을 설명해주세요
REST와 RESTful API 차이
- REST : 웹 서비스가 어떻게 동작해야 하는지에 대한 아키텍쳐 스타일 또는 설계 원칙
- RESTful API : REST 아키텍쳐 스타일을 따르는 웹 API
REST는 이론적인 원칙과 가이드라인, RESTful API는 그 원칙과 가이드라인을 적용한 API
RESTful API 기본 원칙
- 리소스 기반 URI
- 리소스에 대한 작업은 HTTP 메서드를 사용하여 수행 (GET, POST, PUT, PATCH, DELETE)
- 각 요청은 클라이언트의 상태를 서버에 저장하지 않고 독립적으로 처리
- HTTP 상태코드를 사용한 표준화된 응답
- 응답은 캐싱이 가능해야 함
- 계층화된 시스템 - 클라이언트와 서버 간의 상호작용은 중간 계층을 통해 이루어질 수 있음
REST와 RESTful API의 차이는 무엇인가요?
REST는 웹 서비스가 어떻게 동작해야 하는지에 대한 아키텍쳐 스타일이고 RESTful API는 REST 원칙을 따르는 API 입니다.
RESTful API의 주요 설계 원칙을 설명해주세요.
모든 자원은 고유한 URI로 식별되어야 하며(자원기반), 자원에 대한 CRUD작업은 HTTP 메서드를 사용하여 수행합니다(HTTP 메서드 사용) 각 요청은 클라이언트의 상태를 서버에 저장하지 않고 독립적으로 처리하며(무상태성) 응답은 캐시할 수 있어야 한다는 원칙이 있습니다(캐시 가능성).
무상태성의 의미와 장점은 무엇인가요?
무상태성이란 클라이언트의 상태를 서버에서 저장하지 않는것을 의미하며 각 요청이 독립적으로 처리되는것을 의미합니다. 무상태성의 장점은 클라이언트의 상태를 관리할 필요 없이 요청 처리에만 집중할 수 있고 장애 발생 시에도 다른 서버로 요청을 쉽게 전환할 수 있어 장애 복구가 용이합니다. 또한 클라이언트와 서버 간의 결합도가 낮아져 유지 보수가 쉬워집니다.
RESTful API에서 HTTP 상태코드를 사용하는 이유는 무엇인가요?
클라이언트가 요청의 결과를 이해할 수 있도록 하는 표준화된 방법입니다. 클라이언트가 요청이 성공했는지, 실패했는지 등의 결과를 쉽게 파악할 수 있어 클라이언트와 서버간의 명확한 통신을 가능하게 합니다.
REST와 SOAP
REST와 SOAP의 차이점을 설명해주세요
SOAP(Simple Object Access Protocol)
- 서비스 간의 통신을 위한 프로토콜
- XML 기반 메시지 형식을 사용하여 네트워크를 통해 데이터를 교환하며 다양한 프로토콜을 통해 전송
- 메시지가 크고 구조화 되어있어 데이터 교환이 무겁고 복잡함
- 상태 유지 가능, 여러 호출 간 상태 정보 공유 가능
- WS-Security 표준 보안 제공
- WS-AtomicTransaction 표준을 통해 ACID 지원
- 은행, 금융, 전자상거래와 같은 고도의 보안이 필요한 환경에서 사용
- 복잡한 트랜잭션과 보안 요구 사항 처리
REST
- 주로 HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 통신을 수행하는 아키텍쳐 스타일
- 자원을 URI로 식별하고 표준 HTTP메서드를 사용하여 자원에 대한 작업 수행
- 일반적으로 JSON, XML, 텍스트 등 다양한 데이터 형식 지원
- 클라이언트와 서버 간의 데이터 교환이 가볍고 직관적
- 무상태성 유지, 각 요청은 독립적이며 필요한 모든 정보 포함
- 자체 보안 표준은 없지만 HTTPS를 사용하여 데이터 보호 가능
- 본질적으로 무상태라 트랜잭션 관리 기능 제한적
- 웹 기반 애플리케이션, 모바일 애플리케이션, 클라우드 기반 서비스 등에서 사용
- 가볍고 빠른 통신이 필요할 때 적합
REST와 SOAP의 주요 차이점은 무엇인가요?
REST는 아키텍쳐 스타일이고 SOAP는 프로토콜입니다. REST는 주로 HTTP 프로토콜을 사용하여 자원을 URI로 식별하고 SOAP는 다양한 프로토콜을 지원하며 XML 기반의 메시지 형식을 사용합니다. REST는 주로 경량화되어있어 모바일 애플리케이션이나 웹 애플리케이션에 사용되고 SOAP는 고급 보안과 트랜잭션이 필요한 환경에서 사용됩니다.
REST가 SOAP보다 선호되는 이유는 무엇인가요?
REST는 주로 모바일 어플리케이션이나 웹 어플리케이션에서 사용됩니다. REST는 경량화된 통신 방식으로 클라이언트-서버간의 결합도를 낮추고 확장성을 높이며 데이터 전송이 더 간결하고 빠르기때문에 클라우드 및 모바일 애플리케이션에서 더 적합합니다.
3. API 버전 관리
API 버전 관리의 중요성과 방법을 설명해주세요
API 버전 관리
- API가 발전하고 변화함에 따라 클라이언트와 서버 간의 호환성을 유지하기 위해 API의 여러 버전을 관리하는 프로세스
- 새로운 기능을 추가하거나 기존 기능을 변경할 때 기존 사용자에게 영향을 주지 않도록 하는 것이 중요
중요성
- 호환성 유지 : 기존 클라이언트가 API를 계속 사용할 수 있도록 보장, 새로운 버전이 출시되더라도 기존 버전과 호환
- 기능 확장과 개선 : 새로운 기능을 추가하면서도 기존 기능을 안정적으로 제공
- 버그 수정 및 보안 : 구버전에서 발생한 버그나 보안 문제를 해결할 수 있음
- 디비깅 용이성 : 사용하는 버전에 따라 발생할 수 있는 문제를 추적하고 디버깅하기 용이
방법
- URL 경로에 버전 포함
https://api.example.com/v1/resource - 쿼리 파라미터로 버전 지정
- 헤더에 버전 정보 포함
- 미디어 타입에 버전 정보 포함
API 버전을 관리하는 방법을 말씀해주세요
API 버전관리 방법에는 URL 경로에 버전을 포함하는 방법, 쿼리 파라미터에 버전을 추가하는 방법, HTTP 헤더나 미디어 타입에 버전을 포함하는 방법이 있습니다.
API 버전 관리에서 주의해야 할 점은 무엇입니까?
기존 클라이언트가 새로운 버전에도 원활히 작동하도록 호환성을 유지해야 합니다. 각 버전에 대한 상세 문설르 제공하여 변경 상태를 쉽게 이해할 수 있도록 해야 하며 오래된 버전은 폐기하도록 계획을 세워야 합니다.
4. GraphQL
GraphQL과 REST API의 차이점을 설명하고, 실무에서 어떤 상황에 적합한지 이야기해주세요
GraphQL
- 클라이언트가 필요한 데이터를 정확하게 지정할 수 있도록 함
- 단일 엔드포인트에서 모든 데이터 요청을 처리하며, 클라이언트가 어떤 데이터와 그 데이터의 구조를 요청할지 명확히 정의 가능
- 결과적으로 클라이언트는 불필요한 데이터를 받지 않고 필요한 데이터만 가져옴
- 복잡한 쿼리를 생성할 수 있어 서버에 부하가 걸릴 수 있음
- 기본적으로 캐싱 지원 X
REST API와 GraphQL 차이점 데이터 요청 방식
- REST : 고정된 엔드포인트와 HTTP 메서드
- GraphQL : 단일 엔드포인트에서 쿼리를 사용하여 요청
데이터 반환 방식
- REST : 리소스별로 정해진 데이터 구조 반환
- GraphQL : 클라이언트가 요청한 정확한 데이터 구조 반환
과다한 요청
- REST : 하나의 요청으로 필요한 모든 데이터를 가져오지 못할 수 있음
- GraphQL : 클라이언트가 필요한 데이터만 정확히 요청 가능
유연성
- REST : 비교적 제한적
- GraphQL : 매우 유연함
API 버전 관리
- REST : 새로운 기능 추가시 새로운 엔드포인트 필요
- GraphQL : 버전 관리 필요 X
REST API 가 적합한 상황
- 단순한 CRUD 작업
- 캐싱이 중요한 경우
- 기존 시스템과의 통합
GraphQL이 적합한 상황
- 복잡한 데이터 요구 사항
- 데이터 형식이 자주 변경
- 모바일 및 저대역폭 환경 : 필요한 최소한의 데이터만 요청하고 받을 수 있음
5. OAuth 2.0
OAuth 2.0이 무엇이며, 이를 사용한 인증 방식에 대해 설명해주세요
OAuth 2.0
- 사용자 자격 증명을 공유하지 않고 제 3자 어플리케이션이 사용자 데이터를 안전하게 액세스할 수 있도록 허용하는 권한 부여 프로토콜
- 액세스 토큰을 사용하여 권한 부여
- 사용자의 자격 증명을 외부에 노출하지 않고 인증과 권한 부여 분리
인증 흐름
- 권한 부여 요청 : 클라이언트가 리소스 소유자에게 권한 부여 요청
- 권한 부여 승인 : 리소스 소유자가 권한을 승인하면 클라이언트는 권한 부여 코드를 받음
- 액세스 토큰 요청 : 클라이언트는 권한 부여 코드를 권한 부여 서버에게 제출하여 액세스 토큰 요청
- 액세스 토큰 발급 : 권한 부여 서버는 유효한 요청에 대해 액세스 토큰 발급
- 리소스 요청 : 액세스 토큰을 사용하여 리소스 요청
- 리소스 제공 : 액세스 토큰을 확인하고 리소스 제공
특징
- 토큰 기반 인증 : 발급된 토큰을 통해 권한 위임
- 보안 : 사용자 자격 증명을 노출하지 않아 보안 강화
- 범위 제한 : 특정 범위 내에서만 리소스에 접근할 수 있도록 제한
- 사용자 경험 : 한번의 인증으로 여러 서비스에 로그인하거나 데이터를 제공할 수 있어 편리함
인증방식
- 권한 부여 승인 코드 방식
- 사용자가 클라이언트를통해 리소스를 사용하려 할 때 인증 서버에 권한 부여 승인 코드를 요청하고 이 코드를 사용하여 access token과 refresh token을 발급받는 방식
- 암묵적 승인 방식
- 권한 부여 승인 코드를 받는 과정 없이 바로 access token을 받는 방식
- 자원 소유자 자격 증명 승인 방식
- 사용자의 username과 password를 직접 사용하여 access token을 얻는 방식
- 클라이언트 자격 증명 승인 방식
- 클라이언트 자신의 client_id와 client_secret을 사용하여 access token을 받는 방식