산업에서 통합은 애플리케이션 설계에서 중요한 역할을 합니다. 이를 위한 주요 기술 중 하나가 입니다. REST API에 대한 지식은 모든 기술 전문가에게 중요한 기술입니다. 이 기사에서는 취업 면접을 준비하고 기술을 향상시키는 데 도움이 되는 25가지 REST API 질문을 제시합니다. 즐겁게 읽으세요! 소프트웨어 개발 REST API 우선 면접관은 REST API에 대한 질문을 이론과 실무로 나누는 경우가 많습니다. 먼저 용어 및 HTTP 요청 방법에 대한 2~3가지 이론적 질문을 한 후 요청 작성에 대한 실무 작업을 받게 됩니다. 이 글에는 이론적인 질문과 자주 묻는 질문이 포함되어 있으며, 다음 글에서는 REST API와 관련된 실무적인 작업의 예시를 공개할 계획입니다. 인터뷰에서 어떤 질문을 받게 될지는 미리 알 수 없지만, 일반적인 질문 목록을 살펴보는 과정에서 아마도 주제에 대해 더 깊이 알아보고 REST API에 대한 지식을 향상할 수 있을 것이라고 확신합니다. 어떤 경우에도. 이제 기본 용어부터 시작하여 더 복잡한 질문이 있는 섹션을 계속 진행하면서 단순한 것부터 복잡한 것까지 살펴보겠습니다. 1. REST란 무엇인가요? 답변: REST를 언급할 때 종종 동일한 것으로 간주되는 세 가지 용어가 사용되지만 이는 전적으로 사실이 아닙니다. 이러한 용어는 REST, REST API 및 RESTful API입니다. 이제 REST에 대한 답이 나올 것입니다. 이 용어는 Representational State Transfer의 약자이며 프런트 엔드 및/또는 외부 시스템과의 통합이 있는 애플리케이션을 개발하기 위한 HTTP 프로토콜(Hypertext Transfer Protocol)을 기반으로 하는 아키텍처 스타일입니다. REST는 설계된 API 서비스가 따라야 하는 지침을 설명합니다. 이러한 원칙은 HTTP를 사용하여 클라이언트와 서버 간에 요청이 전달되도록 보장합니다. 2. REST API란 무엇인가요? 답변: API는 개별 애플리케이션이 데이터를 통신하고 교환할 수 있도록 하는 프로그래밍 인터페이스입니다. 예를 들어 음식 배달 앱은 Google Maps API를 사용하여 배달원의 위치를 추적하고 이를 지도에 표시할 수 있습니다. REST API는 REST 원칙을 따르는 API로, 모든 데이터를 고유한 URI(Uniform Resource Identifier)로 표시되는 리소스로 처리합니다. 3. RESTful API란 무엇입니까? 답변: RESTful API는 REST의 규칙(또는 "원칙"이라고도 말할 수 있음)에 따라 설계된 API입니다. 즉, REST API와 RESTful API의 차이점은 용어입니다. 첫 번째 사례는 REST 규칙 집합을 의미하고, 두 번째 사례는 REST 규칙을 따르는 특정 API의 구현을 의미합니다. RESTful API라는 용어는 간결함을 위해 REST API 또는 심지어 REST로 대체되는 경우가 많습니다. 시스템 분석가가 애플리케이션 다이어그램에 REST라고 표시된 화살표를 그리는 것은 RESTful API를 의미합니다. 4. REST의 두 가지 주요 원칙은 무엇입니까? 답변: REST API 요청은 두 가지 기본 원칙을 따라야 합니다. 클라이언트와 서버로 분리: 클라이언트와 서버 간의 상호 작용은 요청과 응답의 형태로 수행됩니다. 클라이언트만 요청을 할 수 있고 서버만 응답을 보내 서로 독립적으로 작동할 수 있습니다. 단일 프로토콜: 클라이언트와 서버 간의 상호 작용은 단일 프로토콜을 사용하여 수행되어야 합니다. REST의 경우 이 프로토콜은 HTTP입니다. 5. 당신이 알고 있는 REST의 다른 원칙은 무엇입니까? 답변: 최소한 4개 이상의 원칙을 더 지정할 수 있습니다. REST API 요청은 서버에 상태를 저장하지 않으며 서버 계층을 통과하여 캐시될 수 있습니다. 서버 응답을 통해 실행 가능한 코드를 클라이언트에 보낼 수도 있습니다. 서버 상태 비저장: 서버는 과거 요청/응답에 대한 정보를 저장하지 않습니다. 각 요청과 응답에는 상호작용을 완료하는 데 필요한 모든 정보가 포함되어 있습니다. 상태 비저장 통신은 서버 로드를 줄이고, 메모리를 절약하며, 성능을 향상시킵니다. 계층화된 시스템: 다양한 기능을 수행하기 위해 클라이언트와 API 서버 사이에 계층 형태로 추가 서버가 가능합니다. REST 원칙을 기반으로 구축된 시스템에서 레이어는 모듈식이며 클라이언트와 서버 간의 통신에 영향을 주지 않고 추가하고 제거할 수 있습니다. 캐시 가능성: 서버의 응답은 클라이언트가 성능 향상을 위해 리소스를 캐시할 수 있도록 리소스를 캐시할 수 있는지 여부를 나타냅니다. 요청 시 코드: 서버는 클라이언트 애플리케이션 내 실행에 대한 응답으로 실행 가능한 코드를 클라이언트에 보낼 수 있습니다. 6. 자원이란 무엇입니까? 답변: REST에서는 서버 측에서 액세스 가능한 모든 개체가 리소스로 지정됩니다. 리소스는 유형, 이와 관련된 데이터, 서버의 다른 리소스와의 관계 및 작업에 사용할 수 있는 메서드 목록이 있는 개체입니다. 예를 들어 리소스는 HTML이나 텍스트 파일, 데이터 파일, 이미지나 비디오, 실행 가능한 코드 파일일 수 있습니다. 리소스는 URI(Uniform Resource Identifier)로 식별됩니다. 클라이언트는 HTTP 요청에서 해당 URI를 사용하여 리소스에 액세스합니다. 7. URL이란 무엇입니까? 답변: URI는 통일 자원 식별자(Uniform Resource Identifier)를 나타냅니다. 서버의 리소스를 식별하는 문자열입니다. 각 리소스에는 고유한 URI가 있으며, 이를 HTTP 요청에 포함하면 클라이언트가 해당 리소스에 액세스하고 작업을 수행할 수 있습니다. URI로 리소스를 참조하는 프로세스를 "주소 지정"이라고 합니다. 8. CRUD란 무엇입니까? 답변: CRUD는 "만들기, 읽기, 업데이트, 삭제"를 의미합니다. 이는 REST API를 통해 데이터베이스에서 수행할 수 있는 네 가지 주요 작업입니다. 각 작업에는 고유한 HTTP 요청 메서드가 있습니다. 만들기 = 게시 읽다 = GET 업데이트 = PUT 삭제 = 삭제 9. 서버 응답의 페이로드는 무엇을 의미합니까? 답변: HTTP 응답 페이로드는 클라이언트가 요청한 리소스 데이터를 나타냅니다. 이를 간단히 "HTTP 응답 페이로드"라고도 합니다. 이 데이터는 서버가 정확히 제공하는 내용에 따라 JSON, XML, HTML, 이미지, 파일 등이 될 수 있습니다. 10. REST 메시징이란 무엇입니까? 답변: REST의 메시징은 클라이언트와 서버 간의 메시지 교환을 의미합니다. 통신은 항상 클라이언트가 서버에 HTTP 요청을 하는 것으로 시작됩니다. 서버는 이 요청을 처리한 다음 요청 상태와 클라이언트가 요청한 리소스를 나타내는 HTTP 응답을 다시 보냅니다. 11. REST의 메시지 브로커란 무엇입니까? 답변: REST의 맥락에서 "메시지 브로커"라는 용어는 분산 애플리케이션의 다양한 구성 요소나 시스템 간에 메시지를 전달하는 역할을 하는 미들웨어입니다. 브로커는 다양한 시스템 모듈 간에 비동기 데이터 교환, 메시지 대기열 및 메시지 처리를 제공할 수 있습니다. 메시지 브로커를 사용하여 비동기 작업을 관리하거나 알림을 보낼 수 있습니다. 메시지 브로커는 기본 REST 요소가 아닙니다. 왜냐하면 REST는 HTTP 요청을 사용하는 클라이언트와 서버 간의 동기 통신에 중점을 두기 때문입니다. 12. REST는 어떤 HTTP 요청 방법을 지원합니까? 답변: HTTP 요청 방법은 서버가 리소스에 대해 수행할 원하는 작업을 지정합니다. REST에는 클라이언트에서 서버로 HTTP 요청을 보내는 네 가지 주요 방법이 있습니다. GET: 서버에서 리소스를 요청합니다. 이 메서드는 읽기 전용입니다. POST: 서버에 새 리소스를 생성합니다. PUT: 서버의 기존 리소스를 업데이트합니다. DELETE: 서버에서 리소스를 삭제합니다. 13. POST 방식과 PUT 방식의 차이점은 무엇인가요? 답변: POST는 서버에 리소스를 생성하기 위한 것이고, PUT은 특정 URI의 리소스를 다른 리소스로 바꾸는 것입니다. 이미 연관된 리소스가 있는 URI에 PUT을 사용하면 PUT가 이를 대체합니다. 지정된 URI에 리소스가 없으면 PUT이 리소스를 생성합니다. PUT은 멱등성이 있습니다. 즉, 여러 번 호출하면 리소스가 하나만 생성됩니다. 이는 각 호출이 기존 리소스를 대체하거나 대체할 항목이 없는 경우 새 리소스를 생성하기 때문에 발생합니다. POST는 멱등성이 아닙니다. 예를 들어 POST를 10번 호출하면 각각 고유한 URI가 있는 10개의 서로 다른 리소스가 서버에 생성됩니다. 거의 사용되지 않지만 POST 응답은 캐시될 수 있지만 PUT 응답은 캐시될 수 없습니다. POST 요청은 일반적으로 캐시할 수 없는 것으로 간주되지만 데이터의 "최신"에 대한 명확한 정보가 포함되어 있으면 캐시될 수 있습니다. 더 자세한 답변은 데이터가 "신선"하고 Content-Location(en-US) 헤더가 설정된 경우 POST(또는 PATCH) 요청에 대한 응답을 캐시할 수 있다는 것입니다. 그러나 이는 거의 구현되지 않습니다. 따라서 가능하면 POST 캐싱을 피해야 합니다. 14. HTTP 요청의 주요 부분은 무엇입니까? 답변: REST에는 다음과 같은 HTTP 요청의 기본 구성 요소가 있습니다. 리소스에 대한 요청 방법(예: GET, POST, PUT, DELETE). 서버에서 요청된 리소스를 식별하는 URI입니다. HTTP 버전 – 즉, 서버 응답에 어떤 버전이 있어야 하는지입니다. HTTP 요청 헤더에는 사용자 에이전트, 클라이언트가 허용하는 파일 형식, 요청 본문 형식, 언어, 캐싱 기본 설정 등과 같은 요청에 대한 메타데이터가 포함됩니다. HTTP 요청 본문에는 요청과 관련된 모든 데이터가 포함됩니다. . 이는 요청이 POST 또는 PUT 메서드를 사용하여 서버의 데이터를 변경하는 경우에만 필요합니다. 15. HTTP 응답의 주요 부분은 무엇입니까? 답변: HTTP 응답은 서버에서 클라이언트로 전송됩니다. 요청한 작업이 완료되었는지(또는 완료되지 않았는지)와 요청한 리소스가 전달되었음을 클라이언트에게 알립니다. HTTP 응답에는 네 가지 주요 구성 요소가 있습니다. 사용된 HTTP 버전. 요청 상태 및 HTTP 응답 상태 코드가 있는 상태 표시줄입니다. 시간, 서버 이름, 사용자 에이전트, 반환된 리소스 파일 형식, 캐싱 정보 등 응답에 대한 메타데이터가 포함된 HTTP 응답 헤더입니다. 클라이언트가 요청한 리소스에 대한 데이터가 포함된 HTTP 응답 본문 16. 성공적인 HTTP 서버 응답을 위한 코드를 3개 이상 지정하세요. 답변: 요청이 성공적으로 처리되면 서버는 다음 작업 상태 코드를 반환합니다. 200 OK: 요청이 성공적으로 완료되었습니다. 201 Created: 요청이 성공하여 리소스가 생성되었습니다. 202 Accepted: 이 상태는 서버가 클라이언트의 요청을 수락했지만 처리가 완료되지 않았음을 의미합니다. 처리는 비동기식일 수 있습니다. 17. 요청을 리디렉션할 때 최소 4개의 서버 HTTP 응답 코드를 지정하세요. 답변: 서버는 요청을 리디렉션할 때 다음 상태 코드를 반환합니다. 301 Moved Permanently: 이 상태는 요청한 리소스가 다른 URL로 영구적으로 이동되었으며 클라이언트가 리소스에 액세스하려면 새 URL에 액세스해야 함을 클라이언트에게 알려줍니다. 302 발견됨: 이 상태는 리소스가 일시적으로 다른 URL로 이동되었으며 클라이언트가 일시적으로 새 URL을 사용해야 함을 나타냅니다. 307 임시 리디렉션: 302와 유사하지만 클라이언트는 새 URL에 액세스할 때 동일한 요청 방법을 사용해야 합니다. 308 영구 리디렉션: 301과 유사하지만 클라이언트는 새 URL에 액세스할 때 동일한 요청 방법을 사용해야 합니다. 18. 실패한 HTTP 서버 응답에 대한 코드를 4개 이상 지정하세요. 답변: 요청이 실패하면 서버는 다음 코드를 반환합니다. 400 Bad Request: 요청에 오타나 데이터 누락 등의 오류로 인해 요청이 완료되지 않았습니다. 401 Unauthorized: 클라이언트가 인증되지 않았거나 요청한 리소스에 액세스할 수 있는 권한이 없기 때문에 요청이 완료되지 않았습니다. 403 금지됨: 클라이언트가 인증되었지만 요청한 리소스에 액세스할 수 있는 권한이 없기 때문에 요청이 완료되지 않았습니다. 404 찾을 수 없음: 서버가 요청한 리소스를 찾을 수 없어 요청이 완료되지 않았습니다. 19. 서버 오류 코드를 3개 이상 지정하세요. 답변: 서버에 오류가 있을 경우 서버는 다음 코드를 반환합니다. 500 내부 서버 오류: 서버에 예상치 못한 문제가 발생하여 요청이 완료되지 않았습니다. 502 Bad Gateway: 업스트림 서버의 잘못된 응답으로 인해 요청이 완료되지 않았습니다. 503 서비스를 사용할 수 없음: 유지 관리, 과부하 또는 기타 일시적인 방해로 인해 서버가 요청을 처리할 수 없습니다. 가장 일반적인 HTTP 코드 목록은 확인할 수 있습니다. 여기에서 20. REST와 GraphQL의 차이점은 무엇입니까? 답변: GraphQL은 클라이언트가 필요한 데이터만 쿼리할 수 있도록 하는 쿼리 언어입니다. GraphQL에서 클라이언트는 수신하려는 데이터의 구조와 형식을 정의하고, 서버는 해당 요청에 따라 이를 반환합니다. 주요 차이점은 REST는 각 리소스에 대해 고정된 요청 및 응답 형식을 갖고 있는 반면, GraphQL을 사용하면 클라이언트가 요청을 정의하고 필요한 정보만 얻을 수 있어 더욱 효율적이고 유연하게 사용할 수 있다는 것입니다. 21. REST와 SOAP의 차이점은 무엇입니까? 답변: REST와 SOAP(Simple Object Access Protocol)는 API 구축에 대한 두 가지 접근 방식입니다. 그들 사이에는 3가지 주요 차이점이 있습니다. SOAP는 보안 API 구축을 위한 엄격한 프로토콜입니다. REST는 프로토콜이 아니라 REST 원칙이라는 일련의 지침에 따라 결정되는 아키텍처 스타일입니다. - REST API는 SOAP API보다 구축이 더 간단하고 가벼우며 일반적으로 빠릅니다. SOAP API는 REST API보다 더 안전한 것으로 간주되지만, REST API는 여전히 보안 기능을 구현하여 상당히 안전하게 만들 수 있습니다. - REST는 응답을 캐시할 수 있지만 SOAP는 그렇지 않습니다. SOAP는 데이터를 XML 형식으로 인코딩합니다. - REST를 사용하면 어떤 형식으로든 데이터를 인코딩할 수 있지만 XML과 JSON이 가장 많이 사용됩니다. 22. REST와 AJAX의 차이점은 무엇입니까? 답변: 비동기 JavaScript 또는 AJAX는 웹 애플리케이션에 사용되는 웹 개발 기술 세트입니다. AJAX의 핵심은 웹 페이지가 전체 페이지를 업데이트하지 않고도 서버에 요청하고 페이지 인터페이스를 업데이트할 수 있도록 허용합니다. AJAX 클라이언트는 요청에 REST API를 사용할 수 있지만 AJAX는 REST API로만 작동할 필요는 없습니다. REST API는 AJAX 사용 여부에 관계없이 모든 클라이언트와 통신할 수 있습니다. HTTP 요청과 응답을 사용하여 메시지를 교환하는 REST와 달리 AJAX는 JavaScript에 내장된 XMLHttpRequest 개체를 사용하여 서버에 요청을 보냅니다. 서버 응답은 페이지의 JavaScript 코드에 의해 실행되어 콘텐츠를 변경합니다. 23. REST API 개발에 대한 "계약 우선" 접근 방식은 무엇입니까? 답변: REST API 개발에 대한 Contract First 접근 방식은 실제 개발이 시작되기 전에 API 사양과 계약을 생성하고 정의하는 방법론입니다. 이 계약은 클라이언트가 API와 상호 작용하는 방법과 다양한 요청에서 얻을 수 있는 예상 결과를 정의하는 중요한 문서 역할을 합니다. 24. Contract First의 이점은 무엇입니까? 답변: Contract First 접근 방식의 다음과 같은 장점을 언급할 수 있습니다. 명확한 API 정의: API 사양 및 계약은 API가 클라이언트와 상호 작용하는 방법을 정의합니다. 위험 감소: 고객과의 사전 계약 승인은 API 개발 기대치를 충족하지 못하거나 오해가 발생할 위험을 줄이는 데 도움이 됩니다. 개선된 문서화: 계약서 텍스트는 종종 API에 대한 문서로 사용되어 사용 및 통합이 더 쉬워집니다. 25. REST API 개발에 대한 Code First 접근 방식은 무엇입니까? 답변: REST API 개발에 대한 Code First 접근 방식은 API 기능을 먼저 개발한 다음 해당 기능을 기반으로 API 사양을 자동으로 생성하는 방법론입니다. Code First 접근 방식의 특징은 개발자가 API 논리 작성에 집중하고 해당 논리를 기반으로 문서와 사양을 자동으로 생성할 수 있는 도구를 사용한다는 것입니다. 일반적으로 두 접근 방식인 Code First와 Contract First는 동일한 API 개발 프로젝트 내에서 결합될 수 있습니다. 이 경우 신속한 프로토타이핑을 위해 Code First를 사용하고 계약을 공식화하기 위해 Contract First를 사용합니다. 이 기사가 취업 면접을 준비하거나 REST API에 대한 지식을 새롭게 하는 데 도움이 되기를 바랍니다.
