차례[숨다][보여 주다]
- 1. REST로 무엇을 이해합니까?
- 2. REST API는 무엇을 의미합니까?
- 3. URI가 정확히 무엇인가요?
- 4. RESTful 웹 서비스의 특징은 무엇입니까?
- 5. REST의 기본 원칙은 무엇입니까?
- 6. REST가 지원하는 HTTP 메소드를 언급하십시오.
- 7. 일관된 인터페이스로 인한 제한 사항을 설명합니다.
- 8. REST 리소스란 정확히 무엇입니까?
- 9. JAX-RS는 당신에게 어떤 의미입니까?
- 10. AJAX와 REST의 차이점은 무엇입니까?
- 11. RESTful 웹 서비스의 단점을 나열할 수 있습니까?
- 12. PUT 및 POST 기술을 서로 구별하는 것은 무엇입니까?
- 13. RESTful 웹 서비스를 어떻게 테스트합니까?
- 14. 실제 세계에서 REST API를 설명하십시오.
- 15. 마이크로서비스 아키텍처는 어떻게 작동합니까?
- 16. 캐싱이란 정확히 무엇입니까?
- 17. 페이로드를 설명합니다.
- 18. SOAP와 REST를 구별합니까?
- 19. 전송 계층 보안 프로토콜(TLS)을 REST와 함께 사용할 수 있습니까?
- 20. 멱등 방법: 무엇입니까? RESTful 웹 서비스의 세계에 어떻게 적용됩니까?
- 21. HTTP 기본 인증의 기능은 무엇입니까?
- 22. GraphQL이 마이크로서비스 아키텍처를 만들기 위한 최선의 선택이라고 생각하십니까?
- 23. 안전한 HTTP 메서드와 멱등성 HTTP 메서드의 주요 차이점은 무엇입니까?
- 24. JAX-RS API는 RESTful 루트 리소스 클래스에서 무엇을 의미합니까?
- 25. Postman은 정확히 무엇이며 왜 사용됩니까?
- 26. REST API는 어떻게 안전하게 유지됩니까?
- 결론
REST의 진화는 API를 믿을 수 없을 정도로 액세스할 수 있게 하는 동시에 모든 강점과 잠재력을 드러냈습니다. REST API는 리소스 지향 아키텍처로 인해 쉽게 만들고 캐시할 수 있습니다.
또한 시간이 지남에 따라 RESTful API는 클라우드 컴퓨팅 및 마이크로서비스 기반 설계와 같은 다른 중요한 개발의 선구자였습니다.
따라서 RESTful 서비스를 사용하는 비즈니스에 경쟁 우위를 제공하는 방법을 고려할 때 REST API 개발자가 오늘날 수요가 많다는 것은 놀라운 일이 아닙니다. REST API는 인기 있는 디자인 트렌드입니다.
많은 IT 회사에서 REST API 지식을 원합니다. 소프트웨어 개발자 기술 인터뷰에서 그것에 대해 물어보십시오.
다음은 REST API 개발 분야에서 일하고 싶은 경우 다양한 회사에서 면접을 준비하는 데 도움이 되는 가장 일반적인 REST API 면접 질문입니다.
1. REST로 무엇을 이해합니까?
REST는 HTTP(Hypertext Transfer Protocol)를 기반으로 하는 웹 기반 애플리케이션을 설계하기 위한 아키텍처 패러다임입니다.
REST는 웹 서비스가 RESTful로 간주되기 위해 충족해야 하는 특정 표준을 정의합니다. 이러한 권장 사항은 요청과 리소스가 표준화된 HTTP 프로토콜을 사용하여 클라이언트와 서버 간에 빠르고 효과적으로 전송되도록 보장합니다.
2. REST API는 무엇을 의미합니까?
응용 프로그래밍 인터페이스로 알려진 소프트웨어 대 소프트웨어 링크는 다른 독립적인 프로그램 간의 통신 및 데이터 공유를 가능하게 합니다. 예를 들어 뉴스 웹사이트는 Twitter API를 사용하여 관련 트윗을 자동으로 검색하고 뉴스 기사에 통합할 수 있습니다.
REST 원칙을 준수하는 API를 REST API라고 하며 때로는 RESTful API라고도 합니다. REST API에서 각 데이터 조각은 리소스로 처리되고 고유한 표준 리소스 ID(URI)가 제공됩니다.
예를 들어 Twitter API는 모든 트윗을 클라이언트가 사용할 수 있는 검색 가능한 리소스로 만듭니다. Twitter API는 사용자가 트윗을 게시하고 다른 웹사이트 작업을 수행하는 데 사용할 수 있습니다.
3. URI가 정확히 무엇인가요?
A 컴퓨터 네트워크 리소스는 URI 또는 균일 리소스 식별자를 사용하여 참조할 수 있습니다. 하나의 리소스를 다른 리소스에서 분리하는 수단으로 사용됩니다. 출처는 온라인일 수도 있고 아닐 수도 있습니다.
URI는 표준 구조로 인해 다양한 유형의 리소스에도 쉽게 연결할 수 있습니다. 리소스의 위치 또는 이름은 문자열과 함께 URI에 포함됩니다.
URI는 경로, 체계, 쿼리 및 기타 요소로 구성되지만 프로토콜은 포함하지 않습니다.
프로토콜을 사용하여 URL(Uniform Resource Locators)을 사용하여 인터넷에서 리소스를 찾거나 이를 통해 액세스할 수 있습니다.
4. RESTful 웹 서비스의 특징은 무엇입니까?
- 클라이언트-서버 패러다임은 서비스의 기초입니다.
- 서비스는 URI를 사용하여 리소스에 액세스할 수 있습니다.
- 이 서비스는 HTTP 프로토콜을 활용하여 데이터/리소스를 획득하고 쿼리를 실행하고 기타 작업을 수행합니다.
- 메시징은 클라이언트와 서버 간의 통신에 사용되는 방법의 이름입니다.
- 이러한 서비스는 SOAP 서비스를 사용하여 REST 아키텍처 패턴을 구현할 수도 있습니다.
- 동일한 종류의 반복적인 요청에 대한 서버 호출을 줄이기 위해 이러한 서비스도 캐싱이라는 아이디어를 사용합니다.
5. REST의 기본 원칙은 무엇입니까?
REST API는 다섯 가지 기준을 충족해야 합니다.
클라이언트-서버 분리: 일련의 요청 및 응답만 클라이언트와 서버 간의 통신에 사용할 수 있습니다. 클라이언트와 서버만 각각 요청과 응답을 보낼 수 있습니다. 이 간단한 아이디어를 통해 양 당사자는 서로 독립적으로 기능할 수 있습니다.
균일한 인터페이스: 모든 클라이언트-서버 연결에 대해 균일한 프로토콜이 있어야 합니다. REST용 프로토콜은 HTTP입니다. 각 애플리케이션이 동일한 언어를 사용하여 데이터를 요청하고 전송하기 때문에 일관된 인터페이스로 통합이 더 간단해집니다.
상태 비저장: 서버는 상태 비저장 통신에서 이전 요청 또는 응답의 기록을 저장하지 않습니다. 각 요청과 답변은 교환을 완료하는 데 필요한 모든 세부 정보를 제공합니다. 상태 비저장 통신은 속도를 높이고 메모리를 절약하며 서버의 스트레스를 줄입니다. 또한 불완전한 데이터로 인해 요청이 실패할 가능성을 방지합니다.
계층화된 시스템: 클라이언트와 API 서버 사이에 있는 서버를 계층이라고 합니다. 이러한 추가 서버는 스팸 감지 및 속도 최적화와 같은 다양한 서비스를 수행합니다. REST의 계층은 모듈식이므로 클라이언트와 API 서버 간의 통신에 영향을 주지 않고 추가 및 삭제할 수 있습니다.
캐시 가능: 서버 응답이 리소스를 캐시할 수 있는지 여부를 나타내는 경우 클라이언트는 모든 리소스를 캐시하여 속도를 높일 수 있습니다.
주문형 코딩: 이에 대한 응답으로 API는 실행 가능한 컴퓨터 코드를 고객에게 전송할 수 있습니다. 그러면 클라이언트 애플리케이션은 자체 백엔드에서 코드를 실행할 수 있습니다.
6. REST가 지원하는 HTTP 메소드를 언급하십시오.
REST가 지원하는 HTTP 메서드는 다음과 같습니다.
- GET: 이 메서드는 지정된 URL에서 리소스를 요청합니다. 요청 본문은 무시되므로 포함하지 않아야 합니다. 로컬 또는 서버에서 캐시할 수 있습니다.
- POST: 이 메서드는 처리를 위해 서비스에 데이터를 보내고 서비스는 일반적으로 새 리소스나 변경된 리소스를 반환해야 합니다.
- PUT: 리소스가 요청 URL에서 업데이트됩니다.
- DELETE: 리소스가 요청 URL에서 삭제됩니다.
- 옵션: 지원되는 방법을 식별합니다.
- HEAD: 요청 URL의 메타데이터가 반환됩니다.
7. 일관된 인터페이스로 인한 제한 사항을 설명합니다.
클라이언트와 서버를 분리하기 위해서는 일관된 인터페이스가 필요합니다.
일관된 인터페이스를 구현하려면 다음 네 가지 제약 조건이 필요합니다.
- 리소스 식별: 클라이언트 요청은 표준 리소스 ID를 활용하여 리소스(URI)를 식별해야 합니다.
- 이러한 표현을 사용한 리소스 조작: 클라이언트는 서버에서 리소스 표현을 얻을 때 리소스 상태를 변경할 수 있는 데 필요한 모든 정보를 가지고 있습니다.
- 자체 설명 메시지: 메시지에는 수신자가 메시지를 이해하는 데 필요한 모든 메타데이터 및 기타 정보가 포함됩니다.
- 애플리케이션 상태 엔진으로서의 하이퍼미디어: 클라이언트-서버 통신을 위한 채널은 HTML과 같은 하이퍼미디어이며 클라이언트는 서버 응답을 이해하기 위해 API 관련 문서가 필요하지 않습니다.
8. REST 리소스란 정확히 무엇입니까?
리소스는 REST 아키텍처에서 RESTful 웹 서비스의 기본 구성 요소입니다. 여기에는 API 클라이언트가 액세스해야 하는 모든 중요한 정보가 포함됩니다.
HTML 페이지, 이미지, 비디오 또는 API 활동에 필요한 기타 모든 유형의 리소스는 클라이언트-서버 시스템의 서버를 통해 액세스할 수 있습니다.
자원은 UID(Uniform Resource Identifier)로 식별됩니다. 텍스트, JSON 또는 XML은 모두 허용되는 리소스 표현입니다. 그러나 표현의 형식에는 제한이 없습니다.
9. JAX-RS는 당신에게 어떤 의미입니까?
JAX-RS라고도 하는 RESTful 웹 서비스용 Java API 덕분에 Java에서 RESTful 웹 서비스를 만드는 것이 더 간단합니다. 개발자는 제공된 주석을 사용하여 리소스와 리소스에서 수행할 수 있는 작업을 설명할 수 있습니다.
10. AJAX와 REST의 차이점은 무엇입니까?
Ajax :
- Ajax는 동적 업데이트를 허용하는 기술 그룹입니다. 사용자 인터페이스 페이지를 다시 로드할 필요 없이 요소.
- Ajax는 클라이언트와 서버 간의 비동기 통신을 제거합니다.
쉬다:
- REST는 서버와 클라이언트 간의 통신을 요구합니다.
- REST에서 사용하는 URL 구조와 요청/응답 패턴은 리소스 활용이 중요합니다.
11. RESTful 웹 서비스의 단점을 나열할 수 있습니까?
서비스가 무국적자의 개념을 준수하므로 세션을 유지할 수 없습니다. (클라이언트는 세션 시뮬레이션 전반에 걸쳐 세션 ID를 전달할 책임이 있습니다.)
보안 제약 조건은 REST의 기본이 아닙니다. 이를 사용하는 프로토콜은 보안 예방 조치를 상속합니다. 따라서 SSL/TLS 기반 인증을 통합하는 등 보안 조치를 취하면서 주의를 기울이는 것이 중요합니다.
12. PUT 및 POST 기술을 서로 구별하는 것은 무엇입니까?
놓다:
- PUT 응답에 대한 캐시가 없습니다.
- 멱등원(즉, 여러 요청이 동일한 결과를 낳음)
- 요청의 페이로드가 대상 리소스를 업데이트하거나 대체합니다.
우편:
- 멱등성이 아님(즉, 여러 요청이 동일한 리소스의 배수를 생성함)
- 웹 서버는 의도한 리소스를 기반으로 요청의 페이로드를 처리합니다.
- 적절한 캐시 제어 헤더가 포함되어 있으면 POST 응답을 캐시할 수 있습니다.
13. RESTful 웹 서비스를 어떻게 테스트합니까?
RESTful 웹 서비스 테스트는 Swagger 및 Postman을 비롯한 여러 도구의 도움을 받을 수 있습니다. 쿼리 매개변수, 헤더 및 응답 헤더와 같은 요청 매개변수를 검사하는 것은 후자의 풍부한 기능 덕분에 가능합니다.
Postman을 사용하여 엔드포인트에 요청하고 결과를 표시할 수 있습니다. 그리고 이러한 답변에서 XML과 JSON을 생성할 수 있습니다.
Postman과 Swagger는 모두 매우 유사한 기능을 제공합니다. 반면에 Swagger는 끝점 문서화와 같은 기능도 제공합니다.
14. 실제 세계에서 REST API를 설명하십시오.
- 여행 및 발권 웹사이트는 항공사가 API를 통해 제공하는 비행 시간 및 가격을 활용할 수 있습니다.
- 지도 및 탐색 앱(예: Google 지도)에서 사용하기 위해 대중 교통 기관은 종종 API를 통해 실시간으로 데이터를 공개적으로 제공합니다.
- 날씨 애플리케이션은 날씨 정보를 표시하기 위해 날씨 데이터를 교환하는 개방형 API를 사용합니다.
- 개발자는 여러 호스팅 API를 통해 Google 지도의 매핑 데이터에 액세스할 수 있습니다. 이러한 API는 개발자가 앱과 웹사이트에 동적 지도를 삽입하는 데 사용됩니다.
15. 마이크로서비스 아키텍처는 어떻게 작동합니까?
- 다양한 장치를 사용하여 다양한 고객이 요청을 보냅니다.
- 클라이언트의 ID를 확인한 후 ID 공급자는 보안 토큰을 제공합니다.
- 클라이언트 요청은 API Gateway에서 관리합니다.
- 시스템의 모든 자료는 정적 컨텐츠로 보존됩니다.
- 관리 도구는 노드의 서비스 균형과 결함을 확인합니다.
- 서비스 검색은 마이크로서비스 간의 통신 경로를 검색하는 데 도움이 됩니다.
- 데이터 센터와 프록시 서버는 콘텐츠 전송 네트워크라고 하는 분산 네트워크 시스템을 구성합니다.
- 원격 서비스는 원거리에서 정보 액세스를 제공합니다.
16. 캐싱이란 정확히 무엇입니까?
나중에 더 빨리 액세스하기 위해 서버 응답 사본을 컴퓨터 메모리와 같은 어딘가에 임시로 보관하는 것을 캐싱이라고 합니다.
캐싱은 요청을 충족시키기 위해 서버가 수행해야 하는 작업량을 줄여 REST API를 사용할 때 서버 속도를 향상시킵니다. API를 활용하는 애플리케이션은 리소스가 필요할 때마다 새로운 요청을 제출할 필요가 없기 때문에 캐싱 덕분에 더 빠르게 실행됩니다.
HTTP 응답 헤더의 Cache-Control 필드에는 리소스에 다시 액세스해야 하기 전에 클라이언트가 리소스를 캐시할 수 있는 기간에 대한 정보가 포함됩니다.
17. 페이로드를 설명합니다.
REST의 페이로드는 HTTP 응답 본문에 포함된 정보를 나타냅니다. 고객은 GET 기술을 사용하여 문제의 데이터를 요청했습니다.
예를 들어 특정 트윗에 대해 Twitter API에 요청하는 경우 트윗 텍스트와 웹사이트에 트윗을 올리는 데 필요한 모든 파일이 포함된 문서가 페이로드에 포함됩니다. 또한 POST 메서드를 사용하여 HTTP 요청에 페이로드를 포함할 수 있습니다.
18. 차별화 SOAP 대 REST?
- XML만 처리할 수 있는 SOAP와 달리 REST는 XML, 텍스트, HTML, 그림, 비디오 등을 포함하여 광범위한 리소스 형식을 지원합니다.
- 보안이 온라인 애플리케이션에 중요할 때 SOAP가 도움이 됩니다. REST는 특별히 안전하지 않기 때문에 트랜잭션을 안전하게 완료해야 하는 경우 사용할 수 없습니다.
- SOAP는 프로토콜일 뿐이므로 REST는 웹 서비스에서 이를 사용할 수 있지만 그 반대는 사용할 수 없습니다.
- REST는 웹 서비스를 개발하는 데 사용되는 아키텍처 패턴일 뿐이며 클라이언트-서버 설정, 상태 비저장, 캐시 가능한 응답, 계층화된 시스템 및 일관된 인터페이스와 같은 특정 제한 사항을 준수하지만 SOAP는 엄격하게 준수해야 하는 특정 표준에서 작동하는 프로토콜입니다. 에게.
- REST는 URI(Universal Resource Identifier)를 사용하지만 SOAP는 서비스 인터페이스를 사용하여 클라이언트 애플리케이션에 기능을 제공합니다. REST는 SOAP 메시지가 더 많은 정보를 담고 있기 때문에 SOAP보다 필요한 대역폭이 더 낮습니다.
19. 전송 계층 보안 프로토콜(TLS)을 REST와 함께 사용할 수 있습니까?
사실, 우리는 할 수 있습니다. REST 클라이언트와 서버의 통신은 TLS를 통해 암호화되며 프로토콜은 클라이언트가 서버를 인증할 수 있는 방법도 제공합니다.
SSL(Secure Socket Layer)을 대체하기 때문에 보안 통신(SSL)에 활용됩니다. RESTful 웹 서비스 구현은 TLS 및 SSL 모두와 효과적으로 협력하기 때문에 HTTPS로 성공적입니다.
REST는 구현하는 프로토콜의 특성을 상속합니다. 여기서 한 가지 주의할 점입니다. 결과적으로 보안 보호는 REST가 사용하는 프로토콜에 의존합니다.
20. 멱등 방법: 무엇입니까? RESTful 웹 서비스의 세계에 어떻게 적용됩니까?
URI가 동일한 경우 요청의 일부 HTTP 메서드는 한 번 또는 여러 번 배달되는지 여부에 관계없이 서버에 동일한 영향을 미칩니다. 멱등적 기술은 이러한 기술로 알려져 있습니다.
예를 들어, GET 메서드를 사용하는 URI가 몇 번이나 실행되더라도 서버는 항상 동일한 결과를 경험하게 됩니다. 멱등 방법에는 GET, PUT 및 PATCH가 포함됩니다.
멱등 HTTP 메서드는 RESTful에서 사용하는 메서드 중 일부입니다. 웹 애플리케이션. RESTful 웹 서비스 활동의 일관성을 보장하기 위해 필요합니다.
REST API를 사용하는 고객은 REST API가 실수로 반복 요청을 하도록 하는 코드 오류를 만들 수 있습니다. 이러한 호출은 리소스를 오용할 가능성이 있습니다.
21. HTTP 기본 인증의 기능은 무엇입니까?
기본 인증을 API의 일부로 사용하는 경우 사용자는 사용자 이름과 비밀번호를 제출해야 하며, 이 사용자 이름과 비밀번호는 브라우저에서 "username: password" 형식으로 연결되고 base64로 인코딩됩니다.
브라우저의 모든 HTTP 요청에서 인코딩된 값은 "Authorization" 헤더 값으로 전달됩니다. 자격 증명은 인코딩된 것일 뿐이므로 HTTPS 요청을 보낼 때 이 형식을 사용하는 것이 좋습니다. HTTPS 요청은 안전하지 않고 보안 프로토콜을 사용하지 않으면 누구나 가로챌 수 있기 때문입니다.
22. GraphQL이 마이크로서비스 아키텍처를 만들기 위한 최선의 선택이라고 생각하십니까?
GraphQL은 마이크로서비스 아키텍처를 클라이언트로부터 비밀로 유지하기 때문에 마이크로서비스와 GraphQL은 완벽하게 어울립니다.
프런트 엔드에서는 모든 데이터를 단일 API에서 가져오고, 백 엔드에서는 이를 마이크로서비스로 분할하려고 합니다. 두 가지를 모두 달성하기 위해 내가 알고 있는 가장 좋은 기술은 GraphQL을 사용하는 것입니다.
이를 통해 백엔드를 마이크로서비스로 분할하는 동시에 각 애플리케이션에 단일 API를 제공하고 다양한 서비스의 데이터에서 조인을 활성화할 수 있습니다.
23. 안전한 HTTP 메서드와 멱등성 HTTP 메서드의 주요 차이점은 무엇입니까?
멱등 메서드는 동일한 요청을 통해 한 번 또는 여러 번 호출될 때 동일한 결과를 생성합니다. PUT 메서드는 멱등원입니다.
모든 안전한 방법은 멱등적이지만 안전한 방법은 리소스를 변경하지 않으므로 모든 멱등 방법이 안전한 것은 아닙니다. 예를 들어, GET은 데이터를 검색하기만 하고 리소스를 변경하지 않기 때문에 안전합니다.
또한 멱등적이므로 호출될 때 항상 동일한 응답을 반환합니다.
24. JAX-RS API는 RESTful 루트 리소스 클래스에서 무엇을 의미합니까?
Java Enterprise Edition은 JAX-RS API 요구 사항을 준수하는 클래스와 인터페이스를 제공합니다. JAX-RS를 사용하면 REST 아키텍처 스타일로 Java 웹 서비스를 더 쉽게 작성할 수 있습니다.
JAX-RS API에서 루트 자원 클래스는 "일반 Java 객체" 또는 POJO입니다. 필요한 웹 리소스를 구현하기 위해 JAX-RS 주석을 사용합니다.
@path 주석이 있거나 최소한 하나의 메소드에 @path 주석이 있습니다. API 끝점을 처리하기 위한 메서드가 있는 Java 클래스로 요약할 수 있습니다.
25. Postman은 정확히 무엇이며 왜 사용됩니까?
Postman이라는 API 개발 도구는 API를 생성, 테스트 및 수정하는 데 사용됩니다. 이 도구는 개발자가 API에 필요한 모든 기능에 사용할 수 있습니다. 개발자의 작업을 단순화하고 용이하게 합니다.
Postman을 사용하면 GET, POST, PUT 및 PATCH를 비롯한 다양한 HTTP 쿼리를 쉽게 만들고 나중에 사용할 수 있도록 환경을 저장하고 API를 다양한 언어로 된 코드로 변환할 수 있습니다.
API 주기의 각 단계는 Postman을 사용하여 더 간단해지고 더 빠른 API 개발을 위해 협력이 간소화됩니다.
또한 개발자는 문서, 사양, 테스트 케이스, 프로세스 및 API 카탈로그를 관리할 수 있습니다.
26. REST API는 어떻게 안전하게 유지됩니까?
REST API는 SOAP API만큼 엄격한 보안 보호 수단을 사용하지 않기 때문에 민감한 데이터는 이를 사용하여 보내거나 검색해서는 안 됩니다.
그러나 신뢰할 수 있는 REST API는 안전하고 신뢰할 수 있는 데이터 전송을 위해 보안 제어를 계속 통합합니다.
- 인증 및 권한 부여: API에 대한 각각의 모든 요청은 이 두 가지 검사를 통과해야 합니다. 인증을 통해 클라이언트의 신원을 확인하는 것과 승인을 통해 요청된 리소스에 액세스할 수 있는 권한이 있는지 확인하는 것은 서로 다른 두 가지 프로세스입니다.
- 유효성 검사: API가 리소스에 대한 액세스 권한을 부여하기 전에 인증 및 권한 부여 후에 유해할 수 있는 코드가 있는지 요청을 계속 확인해야 합니다. 따라서 서버는 주입 공격에 노출될 수 있습니다.
- 유효성 검사: API가 리소스에 대한 액세스 권한을 부여하기 전에 인증 및 권한 부여 후에 유해할 수 있는 코드가 있는지 요청을 계속 확인해야 합니다. 따라서 서버는 주입 공격에 노출될 수 있습니다.
- 암호화: TLS/SSL 암호화는 클라이언트와 서버 간의 연결을 보호하고 해커가 요청과 응답을 가로채지 못하도록 합니다.
- 제한 및 스로틀링과 같은 속도 제한 기술은 성능 저하 또는 충돌을 목표로 하는 DDoS와 같은 무차별 대입 공격으로부터 서버를 보호합니다.
- URI에 민감한 정보 없음: 리소스의 URI에는 보호된 데이터(예: 사용자 이름, 암호 또는 인증 토큰)가 포함되어서는 안 됩니다.
결론
축하합니다! 복잡한 REST API 인터뷰 질문에 대한 몇 가지 기본 질문과 해당 솔루션이 이제 여러분의 손끝에 있습니다.
이제 몇 가지 일반적인 REST API 인터뷰 질문에 응답하는 방법에 대한 좋은 개념을 얻었으므로 인터뷰에 응답할 수 있습니다. 다음 단계는 목표에 따라 다릅니다.
방문 인터뷰 시리즈 인터뷰를 준비하기 위해 Hashdork와 함께.
댓글을 남겨주세요.