기술면접_RESTful API

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

• RESTful API는 Representational State Transfer(표현 상태 전이)를 따르는 API입니다.
  웹 상의 자원을 HTTP 프로토콜을 이용해 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 웹 서비스를 제공합니다. RESTful API는 각 자원에 대해 고유한 URI를 할당하고, HTTP 메서드를 이용하여 자원을 조작합니다.

  RESTful API의 특징은 다음과 같습니다.

  • 각 자원은 고유한 URI를 가지며, 이를 통해 자원을 식별합니다.

  • HTTP 메서드(GET, POST, PUT, DELETE 등)를 이용하여 자원을 조작합니다.

  • JSON, XML 등의 데이터 포맷을 이용하여 데이터를 주고받습니다.

  • Stateless(무상태)한 통신 방식(서버-클라이언트 구조)

  • 하나의 자원은 하나의 URI를 가지고 URI에 의해 자원의 상태가 결정됩니다.

    RESTful API는 간결하고 직관적인 API 설계가 가능하며, 다양한 클라이언트(웹, 모바일 등)에서 쉽게 사용될 수 있습니다. 또한, HTTP의 기본적인 기능을 이용하므로 서비스의 확장성과 재사용성이 높습니다.

RESTful API에서 HTTP 메서드 중에 어떤 것들이 있나요? 어떤 역할을 하는지?

RESTful API에서는 다음과 같은 HTTP 메서드가 사용됩니다.

1. GET: 리소스를 조회할 때 사용합니다. 서버에서 해당 리소스를 응답 바디에 포함하여 반환합니다.

2. POST: 새로운 리소스를 생성할 때 사용합니다. 요청 바디에 새로운 리소스를 포함하여 서버에 전달합니다.

3. PUT: 기존의 리소스를 수정할 때 사용합니다. 요청 바디에 수정된 리소스를 포함하여 서버에 전달합니다.

4. DELETE: 특정 리소스를 삭제할 때 사용합니다.

5. PATCH: 기존 리소스의 일부를 수정할 때 사용합니다. 요청 바디에 수정 내용을 포함하여 서버에 전달합니다.

6. HEAD: GET 메서드와 유사하지만, 응답 바디가 없이 해당 리소스의 메타데이터만 반환합니다.

7. OPTIONS: 서버가 제공하는 리소스에 대한 옵션들을 조회할 때 사용합니다.

   HTTP 메서드는 RESTful API의 핵심이며, 각 메서드는 명확한 역할을 가지고 있습니다. 이를 적절히 사용하여 API를 설계하면, 클라이언트와 서버 간에 명확한 인터페이스가 확립되어 서로간의 상호작용이 원활하고 안정적으로 이루어질 수 있습니다.

RESTful API에서 리소스와 리소스의 상태는 어떻게 다른가요?

• RESTful API에서 리소스는 URI(Uniform Resource Identifier)로 식별되는 정보의 개념을 말합니다. 즉, 서버에 있는 모든 데이터나 객체, 파일 등을 리소스로 취급할 수 있습니다. 각각의 리소스는 고유한 식별자(URI)를 가지며, 클라이언트는 이 식별자를 이용해 서버에 요청을 보냅니다. 반면에 리소스의 상태는 URI를 통해 식별되는 리소스의 현재 상태를 말합니다. 클라이언트가 서버에 요청을 보내면 서버는 해당 리소스의 상태를 클라이언트에게 반환합니다. 이때 반환되는 상태 정보는 JSON이나 XML 형태로 제공되며, 클라이언트는 이 정보를 이용해 애플리케이션 로직을 처리하게 됩니다. 예를 들어, RESTful API에서 사용자 정보를 나타내는 리소스는 /users와 같은 URI로 식별될 수 있습니다. 이 리소스의 상태는 GET 메서드로 요청하면 사용자의 정보를 JSON이나 XML 형태로 반환합니다. 클라이언트는 이 정보를 이용해 사용자 정보를 보여주는 애플리케이션 로직을 처리하게 됩니다.
  

RESTful API에서 클라이언트와 서버는 어떤 역할을 하나요?

• RESTful API에서 클라이언트와 서버는 각각의 역할을 수행합니다. 클라이언트는 리소스를 식별하고 리소스의 상태를 변경하는데 사용할 수 있는 HTTP 메서드를 보낼 수 있습니다. 또한 서버에서 제공되는 리소스를 사용하여 애플리케이션을 작성할 수 있습니다. 서버는 리소스를 관리하고, 클라이언트가 보낸 요청에 대한 응답을 반환합니다. 서버는 데이터를 저장하고 수정하며, 클라이언트가 요청한 리소스에 대한 적절한 응답을 반환합니다. 이러한 역할을 수행하면서 서버는 클라이언트에게 전달할 수 있는 상태 코드를 사용하여 리소스에 대한 처리 결과를 알릴 수 있습니다.
  

RESTful API에서 Hypermedia란 무엇인가요?

• RESTful API에서 Hypermedia란, 서버로부터 클라이언트에게 전송되는 리소스에 대한 추가 정보를 제공하기 위해 사용되는 링크와 리소스 메타데이터를 포함하는 매체입니다. 즉, 클라이언트는 서버로부터 리소스를 요청하면서 동시에 해당 리소스와 관련된 링크 정보를 함께 받아옵니다. 이러한 링크 정보를 이용하여 클라이언트는 서버로부터 다음에 어떤 리소스를 요청해야 하는지를 결정할 수 있게 됩니다. 이러한 Hypermedia는 RESTful API에서 가장 중요한 개념 중 하나입니다. 클라이언트가 서버와 상호작용할 수 있는 방법을 제한하지 않으면서, 클라이언트가 필요한 정보를 서버로부터 얻을 수 있도록 도와줍니다. 이를 통해 RESTful API는 유연하고 확장 가능한 시스템을 구축할 수 있게 됩니다.
  

RESTful API에서 CRUD(Create, Read, Update, Delete) 연산은 어떻게 구현하나요?

• RESTful API에서 CRUD 연산은 HTTP 메서드를 이용하여 구현합니다. 각각의 메서드는 다음과 같은 기능을 수행합니다.

  • Create: POST 메서드를 사용하여 새로운 리소스를 생성합니다.

  • Read: GET 메서드를 사용하여 리소스를 조회합니다.

  • Update: PUT 또는 PATCH 메서드를 사용하여 리소스를 수정합니다.

  • Delete: DELETE 메서드를 사용하여 리소스를 삭제합니다.

    예를 들어, 새로운 사용자를 생성하는 경우에는 POST 메서드를 사용하여 서버로 요청을 보내고, 서버는 새로운 사용자를 생성하고 해당 사용자의 정보를 담은 리소스를 반환합니다. 사용자 정보를 수정하는 경우에는 PUT 또는 PATCH 메서드를 사용하여 서버로 요청을 보내고, 서버는 해당 사용자의 정보를 수정하고 결과를 반환합니다. 사용자 정보를 삭제하는 경우에는 DELETE 메서드를 사용하여 서버로 요청을 보내고, 서버는 해당 사용자의 정보를 삭제하고 결과를 반환합니다. 이러한 방식으로 RESTful API에서 CRUD 연산을 구현할 수 있습니다.

RESTful API에서 JSON, XML 등의 데이터 형식을 사용하는 이유는 무엇인가요?

• 1. 인간이 읽기 쉽고 이해하기 쉽다
     JSON, XML 등의 데이터 형식은 인간이 읽기 쉽고 이해하기 쉬운 형태를 가지고 있습니다. 이는 디버깅 및 개발 과정에서 유용하며, API를 사용하는 사용자도 이해하기 쉽고 직관적으로 사용할 수 있습니다.
  2. 다양한 시스템 간의 상호 운용성을 보장한다
     RESTful API는 다양한 클라이언트와 서버 간의 상호 운용성을 보장하기 위해 설계되었습니다. JSON, XML 등의 데이터 형식은 다양한 시스템 간에 데이터를 교환하기에 적합하며, 이를 사용함으로써 다양한 시스템 간의 상호 운용성을 높일 수 있습니다.
  3. 쉽게 파싱되고 생성할 수 있다
     JSON, XML 등의 데이터 형식은 쉽게 파싱되고 생성할 수 있는 형태를 가지고 있습니다. 이를 사용하면 API 서비스를 구현하는 데 드는 노력과 비용을 줄일 수 있습니다.
  4. 간결하고 가벼운 구조를 가지고 있다
     JSON, XML 등의 데이터 형식은 간결하고 가벼운 구조를 가지고 있습니다. 이는 데이터 전송에 필요한 대역폭과 저장 공간을 줄일 수 있으며, API의 처리 성능을 향상시키는 데 도움을 줍니다.

RESTful API에서 인증과 인가는 어떻게 처리하나요?

• 1. 인증(Authentication)

     • 클라이언트가 보호된 리소스에 접근하려면 먼저 자신의 신원을 인증해야 합니다.
     • 이를 위해 일반적으로 HTTP 헤더에 인증 정보를 담아서 서버로 전송합니다.
     • 인증 정보는 보통 ID와 패스워드를 조합한 토큰이나 API 키 등을 사용합니다.
     • RESTful API에서는 일반적으로 HTTPS 프로토콜을 사용하여 인증 정보를 암호화하여 전송합니다.

  2. 인가(Authorization)
     - 클라이언트가 인증되었다면, 서버는 클라이언트가 요청한 작업을 수행할 수 있는 권한이 있는지 확인해야 합니다.
     - 이를 위해 일반적으로 클라이언트의 인증 정보를 기반으로 서버에서 사용자의 권한을 확인합니다.
     - 권한 확인이 완료되면 서버는 클라이언트의 요청에 대한 적절한 응답을 반환합니다.
     - 예를 들어, 인증된 사용자가 관리자 권한을 가지고 있다면, 서버는 해당 사용자에게 관리자 권한이 필요한 리소스에 대한 접근을 허용합니다.

     RESTful API에서는 일반적으로 인증 및 인가를 처리하기 위해 OAuth, JWT 등의 프로토콜과 라이브러리를 사용합니다.

Stateful, Stateless 서버-클라이언트 구조에 대해서

• Stateful한 서버-클라이언트 구조에서는 서버가 클라이언트의 이전 상태를 계속해서 유지합니다. 이전 상태를 유지하므로서, 클라이언트는 매번 모든 정보를 서버에게 보내지 않아도 됩니다. 이 방식은 상태 정보가 많이 필요하거나, 트랜잭션 처리가 필요한 경우에 적합합니다. 예를 들어, 인터넷 뱅킹에서는 로그인 후 계좌 잔액 조회, 송금, 이체 등의 요청을 연속적으로 처리할 때, 계좌 정보를 클라이언트에서 계속 유지하지 않고 서버에서 유지하면 효율적입니다. 반면 Stateless한 서버-클라이언트 구조에서는 클라이언트의 상태 정보를 서버가 유지하지 않습니다. 클라이언트가 요청을 보낼 때마다 모든 정보를 함께 보내야 합니다. 이 방식은 클라이언트가 매우 간단하고 가벼운 구조를 갖추어야 할 때 유리합니다. 예를 들어, 검색 엔진에서는 검색어를 입력받아 결과를 반환해주는 역할을 하는데, 상태 정보를 유지할 필요가 없으므로 Stateless한 방식이 적합합니다. RESTful API에서는 보통 Stateless한 방식이 사용됩니다. 이는 서버가 클라이언트의 상태를 유지하지 않고, 요청을 보낼 때마다 필요한 정보를 모두 함께 보내기 때문입니다. 이 방식은 확장성과 성능 면에서 이점이 있습니다.
  
  예를 들어서, 구글에서 로그인을 한 상태에서 검색 기능을 사용하는 것은 Stateful과 Stateless한 방식을 둘 다 사용하는 것인가? 구글에서 로그인을 한 상태에서 검색을 사용하는 경우, 일부 기능은 Stateful 방식을 사용하고, 일부 기능은 Stateless한 방식을 사용합니다. 예를 들어, 구글 검색은 Stateless한 방식으로 작동합니다. 즉, 검색 요청을 보내고 검색 결과를 받은 후 서버와의 연결을 끊습니다. 하지만 구글의 로그인 기능은 Stateful한 방식으로 작동합니다. 즉, 사용자가 로그인을 한 후에는 세션 정보가 서버에 유지되며, 사용자가 로그아웃을 하기 전까지는 해당 세션 정보를 계속 유지합니다. 따라서, 구글 검색을 사용할 때는 서버와의 연결을 유지하지 않으므로 Stateless한 방식으로 작동하며, 로그인 기능을 사용할 때는 세션 정보를 유지하므로 Stateful한 방식으로 작동합니다.
  
  로그인을 할 때 POST 메서드로 ajax 요청을 보내서 로그인을 하게 되는데 이것은 Stateful이 아닌건가? 로그인 요청을 POST 메서드로 보내는 것은 HTTP 프로토콜 자체는 Stateless 하지만, 로그인 이후 클라이언트와 서버 간의 상호작용에서는 Stateful 하게 됩니다. 즉, 로그인 요청을 통해 발급된 인증 토큰 등의 정보를 클라이언트 측에서 저장하고 이를 이용해 다음 요청을 할 경우, 클라이언트가 서버에 인증 정보를 전달하고 서버는 이를 이용하여 클라이언트의 상태를 파악하게 되어 Stateful 하게 됩니다. 따라서, 로그인 요청은 Stateless 하지만, 로그인 이후에는 Stateful 하게 됩니다. 결론. 서버와 클라이언트 간의 구조는 다양하며, 단일 서버가 여러 가지 구조를 가질 수 있습니다. 예를 들어, 하나의 서버가 여러 클라이언트에게 RESTful API와 같이 stateless한 방식으로 데이터를 제공하면서, 동시에 채팅과 같이 stateful한 방식으로 데이터를 처리하는 기능을 제공할 수 있습니다. 이는 서버가 서로 다른 클라이언트 요청에 대해 각각 다른 방식으로 응답할 수 있기 때문입니다. 따라서 서버와 클라이언트 간의 구조는 상황에 따라 유연하게 변경될 수 있습니다.
  

최근 Stateless 한 개발이 트렌드인 이유

• 1. 확장성: Stateless한 서버는 클라이언트 요청에 대한 응답만 처리하므로, 여러 대의 서버로 쉽게 확장할 수 있습니다. 반면에, Stateful한 서버는 클라이언트 상태를 유지하기 때문에 서버 확장이 어렵고 복잡합니다.
  2. 안정성: Stateless한 서버는 서버 사이드에서 클라이언트 정보를 저장하지 않기 때문에, 서버에 저장된 정보가 유출되는 것을 방지할 수 있습니다. 또한, 서버가 재시작되는 경우에도 클라이언트 정보가 유실되지 않습니다.
  3. 유지 보수성: Stateless한 서버는 클라이언트 정보를 유지하지 않으므로, 서버에 저장된 데이터를 관리하는 데 필요한 코드가 없습니다. 이로 인해, 코드 유지 보수가 쉬워집니다.
  4. 상호 운용성: Stateless한 서버는 클라이언트와 서버 간에 상호 운용성을 높일 수 있습니다. 이는 서버와 클라이언트가 서로 다른 기술 스택을 사용하더라도 상호 작용할 수 있게 만들어 줍니다.
  5. 성능: Stateless한 서버는 클라이언트 정보를 저장하지 않기 때문에, 처리해야 할 요청이 줄어들어 처리 성능을 향상시킵니다. 또한, 클라이언트 정보를 서버에 저장하지 않기 때문에, 서버에서 데이터를 검색하고 저장하는 시간을 절약할 수 있습니다.