[ 직무 면접 대비 ] 웹 개발 직무 인터뷰 모음 1

 

   +   웹 통신의 4요소는 무엇인가요?

• HTML
• URL
• Web Server, Web Client
• HTTP

 

 

   +   REST에 대해 설명해보세요.

• Representational State Transfer의 약자
• 설계 기본 규칙으로
  
  • URL를 통해 자원을 명시하고
  • HTTP method (GET, POST, PUT, DELETE)를 통해 자원을 처리하도록 설계된 아키텍처
• 구성
  • URI, HTTP method, Payload (HTTP Request에서 보내는 데이터)

 

 

   +   RESTful에 대해 설명해보세요.

• REST 아키텍처를 구현하는 웹 서비스를 나타내는 것입니다.

 

 

   +   [GET]에 대해 설명해보세요.

• 요청하는 데이터가 HTTP Request Message의 Header 부분의 URL에 담겨서 전송됩니다.
  → URL이라는 공간에 담겨있기 때문에 전송할 수 있는 데이터의 크기가 제한적입니다.
  → 또 보안이 필요한 데이터에 대해서는 데이터가 그대로 URL에 노출되므로 GET 방식은 적절하지 않습니다.
• 서버에서 어떤 데이터를 가져와서 보여주는 용도입니다.
• GET 요청은 브라우저에서 Caching 할 수 있습니다.
• 요청받은 URI의 정보를 검색하여 응답합니다.

 

 

   +   [POST]에 대해 설명해보세요.

• HTTP Message의 Body 부분에 데이터가 담겨서 전송됩니다.
• 서버의 값이나 상태를 변경하거나 추가하기 위해서 사용됩니다
•  새로 작성된 리소스인 경우 HTTP 헤더 항목 Location : URI주소를 포함하여 응답합니다.
• POST는 보통 INSERT의 개념

 

 

   +   [PUT]에 대해 설명해보세요.

• 요청된 자원을 수정(UPDATE)한다. 내용 갱신을 위주로 Location : URI를 보내지 않아도 됩니다. 클라이언트 측은 요청된 URI를 그대로 사용하는 것으로 간주합니다.
• PUT은 UPDATE개념으로  해당 자원 전체를 교체합니다.

 

 

   +   [HEAD]에 대해 설명해보세요.

• GET방식과 동일하지만, 응답에 BODY가 없고 응답 코드와 HEAD만 응답합니다.
• 웹서버 정보 확인, 버전 확인, 최종 수정 일자 확인 등의 용도로 사용됩니다.

 

 

   +   [PATCH]에 대해 설명해보세요.

• PUT과 유사하게 요청된 자원을 수정(UPDATE)할 때 사용됩니다. PUT의 경우 자원 전체를 갱신하는 의미지만, PATCH는 해당 자원의 일부를 교체하는 의미로 사용.
• PATCH는 일부를 변경한다는 의미입니다.

 

 

   +   [DELETE]에 대해 설명해보세요.

• 요청된 자원을 삭제할 것을 요청합니다. (안전성 문제로 대부분의 서버에서 비활성)

 

 

   +   RESTful 웹 서비스에 대해 어떻게 이해하고 있습니까?

• XML 방식으로 웹 서비스를 개발하는 데 사용되는 SOAP (Simple Object Access Protocol)와 마찬가지로 RESTful 웹 서비스는 웹 프로토콜 즉, HTTP 프로토콜 방식을 사용합니다. 확장성, 유지 보수성, 다양한 프로그래밍 언어로 구축된 여러 애플리케이션 통신을 지원하는 등의 기능이 있습니다.
• RESTful 웹 서비스 구현은 클라이언트가 필요로 하는 다양한 리소스에 액세스 하는 방법을 정의하며 그는 웹 브라우저를 통해 서버로 요청을 보냈습니다.
• 이 구현의 중요한 측면은 다음과 같습니다.
  • 자원
  • 요청 헤더
  • 요청 본문
  • 응답 본문
  • 상태 코드

 

 

   +     RESTful 웹 서비스에서 사용하는 프로토콜의 이름을 지정하십시오.

• RESTful 웹 서비스는 HTTP 프로토콜을 사용합니다. 이것은 클라이언트와 서버 간의 데이터 통신 매체 역할을 합니다. HTTP 표준 메서드는 RESTful 웹 서비스 아키텍처의 리소스에 액세스 하는 데 사용됩니다.

 

 

   +   RESTful 웹 서비스와 관련하여 '주소 지정'이라는 용어를 설명하십시오.

• 모든 사람에게 도달하기 위해 우편 번호가 있는 주소가 필요한 것과 마찬가지로 '주소 지정'은 웹 서비스를 호스팅 하기 위해 서버에 있는 리소스를 찾습니다. 이것은 일반적으로 URI 즉, 통합 리소스 식별자로 수행됩니다.

 

 

   +   RESTful 웹 서비스의 기능을 등록하십시오.

• 모든 RESTful 웹 서비스에는 아래에 나열된 다음과 같은 기능과 특성이 있어야 합니다.
  • 클라이언트-서버 표현을 기반으로 합니다.
  • 웹 서비스에서 데이터 가져오기, 리소스 검색, 쿼리 실행 등과 같은 기능을 수행하기 위해 HTTP 프로토콜을 사용합니다.
  • 서버와 클라이언트 간의 통신은 '메시징'이라는 매체를 통해 수행됩니다.
  • URI를 통해 서버에서 사용 가능한 리소스 주소 지정.
  • 모든 클라이언트 요청과 응답이 서로 독립적인 상태 비 저장 개념을 기반으로 하며 필요한 정보를 완벽하게 제공합니다.
  • 캐싱 개념을 사용합니다.
  • Uniform 인터페이스에서 작동합니다.

 

 

   +   HTTP 요청 및 HTTP 응답의 핵심 구성 요소는 무엇입니까?

• HTTP 요청의 핵심 구성 요소는 다음과 같습니다.
  • 동사: GET, PUT, POST 등과 같은 메서드를 포함합니다.
  • 서버에서 사용 가능한 리소스를 식별하기 위한 Uniform Resource Identifier입니다.
  • HTTP 버전을 지정하기 위한 HTTP 버전입니다.
  • 데이터에 대한 정보를 포함하기 위한 HTTP 요청 헤더입니다.
  • 사용 중인 리소스의 표현을 포함하는 HTTP 요청 본문입니다.
• HTTP 응답의 핵심 구성 요소는 다음과 같습니다.
  • 요청 코드: 여기에는 서버 응답의 상태를 결정하는 다양한 코드가 포함됩니다.
  • HTTP 버전을 지정하기 위한 HTTP 버전입니다.
  • 데이터에 대한 정보를 포함하기 위한 HTTP 응답 헤더입니다.
  • 사용 중인 리소스의 표현이 포함된 HTTP 응답 본문입니다.

 

 

   +   RESTful 웹 서비스에 대한 몇 가지 중요한 제약 조건을 말해보세요.

• 모든 제약은 긍정적인 영향과 부정적인 영향을 미치며 전체 아키텍처를 생성하려면 둘 사이에 균형이 있어야 합니다.
• 다음은 RESTful 웹 서비스에 대한 몇 가지 중요한 제약 사항입니다.
  • 응용 프로그램 내에서 모듈성을 유지하는 데 도움이 되는 각 서버와 클라이언트에 대해 별도의 문제가 있어야 합니다. 이것은 또한 복잡성을 줄이고 확장 성을 증가시킵니다.
  • 클라이언트-서버 통신은 상태 비 저장이어야 합니다. 즉, 이전 정보가 사용되지 않고 전체 실행이 분리되어 수행됩니다. 실패한 경우 클라이언트가 복구하는데도 도움이 됩니다.
  • 클라이언트-서버 통신에서 HTTP 응답은 캐시 가능해야 합니다. 그래야 필요할 때 캐시 된 사본을 사용할 수 있어 서버의 확장 성과 성능이 향상됩니다.
  • 네 번째 제약은 클라이언트-서버 상호 작용을 쉽게 이해할 수 있는 균일 한 인터페이스입니다. 이 제약은 다음과 같이 4 개의 하위 제약으로 더 나뉩니다.
    • 자원 식별
    • 자원 조작
    • 각 메시지는 쉽게 이해할 수 있으며 설명이 포함되어 있습니다.
    • 하이퍼 링크가 있는 텍스트로 정의되는 하이퍼 미디어를 클릭하면 다른 응용 프로그램 상태로 이동합니다.
  • 클라이언트-서버 통신은 계층화된 시스템에서 수행되어야 하며 따라서 클라이언트는 통신이 수행되는 중간 수준에 대한 지식만 있어야 합니다.

 

 

   +   PUT 방식과 POST 방식의 차이점은 무엇인가요?

• PUT 방법과 POST 방법의 가장 큰 차이점은 PUT 방법으로 생성된 결과는 작업이 몇 번 수행되더라도 항상 동일하다는 것입니다. 반면에 POST 작업에 의해 생성되는 결과는 항상 매번 다릅니다.

 

 

   +   RESTful 웹 서비스에 대한 리소스 표현을 디자인할 때 염두에 두어야 할 몇 가지 중요한 사항을 나열해보세요.

•  리소스 표현이 수행되는 형식에는 제한이 없지만 주요 요구 사항은 표현의 형식이 클라이언트 요구 사항에 따라야 한다는 것입니다.
• 좋은 자원 표현은 다음과 같은 주요 사항을 고려하여 설계됩니다.
  • 리소스 표현 형식은 클라이언트와 서버가 쉽게 이해할 수 있어야 합니다.
  • 표현은 복잡하거나 단순할 수 있는 형식 구조에 관계없이 완전해야 합니다.
  • 자원을 다른 자원에 연결하는 경우에도 이러한 경우를 고려하고 처리해야 합니다.

 

 

   +    HTTP 상태 코드는 무엇입니까? 의미를 가진 소수에 대해 말해보세요.

•  HTTP 상태 코드는 기본적으로 서버에서 수행된 작업의 상태를 일부 코드의 모드로 표현한 것입니다. 모든 코드에는 고유 한 의미가 있습니다.
• 의미가 있는 일부 HTTP 상태 코드는 다음과 같습니다.
  • 코드 200 : 성공을 나타냅니다.
  • 코드 201 : 리소스가 성공적으로 생성되었음을 나타냅니다.
  • 코드 204 : 응답 본문에 내용이 없음을 나타냅니다.
  • 코드 404 : 사용할 수 있는 방법이 없음을 나타냅니다.

 

 

   +   RESTful 웹 서비스를 설계할 때 따라야 할 모범 사례는 무엇입니까?

• 안전한 RESTful 웹 서비스를 설계하려면 몇 가지 모범 사례 또는 고려해야 할 사항이 있습니다.
• 다음과 같이 설명됩니다.
  • 서버의 모든 입력을 확인해야 합니다.
  • 입력은 올바른 형식이어야 합니다.
  • URL을 통해 민감한 데이터를 전달하지 마십시오.
  • 모든 세션에서 사용자는 인증을 받아야 합니다.
  • 오류를 나타내는 데는 HTTP 오류 메시지만 사용해야 합니다.
  • 쉽게 이해할 수 있고 클라이언트에 필요한 메시지 형식을 사용하십시오.
  • 통합 리소스 식별자는 설명적이고 쉽게 이해할 수 있어야 합니다.

 

 

   +   '리소스'란 무엇입니까?

• 'Resource'는 이미지, HTML 파일, 텍스트 데이터 및 모든 동적 유형이 될 수 있는 유형의 객체로 정의됩니다. 데이터. 자원을 표현하기 위해 사용할 수 있는 다양한 표현 형식이 있습니다.
• 가장 일반적인 리소스는 다음과 같습니다.
  • JSON
  • YAML
  • XML
  • HTML