Learn then Key points/Tech Interview Questions

10. Backend

Nomad Kim 2021. 3. 29. 14:42

1. Restful api 란? 사용 시 장점과 단점은?

Representational State Transfe라는 용어의 약자이다.
자원을 URI로 표시하고 해당 자원의 상태를 주고 받는 것을 의미한다.

REST의 구성 요소는

  • 자원(Resource): URI
  • 행위(Verb): HTTP METHOD
  • 표현(Representations)
    로 이루어져 있다.

즉 Rest는 URI를 통해 자원을 표시하고, HTTP METHO를 이용하여 해당 자원의 행위를 정해주며
그 결과를 받는 것을 말한다.

 

REST의 특징

  1. Uniform Interface (유니폼 인터페이스)
    HTTP 표준만 따른다면 어떤 언어 혹은 어떤 플랫폼에서 사용하여도 사용이 가능한 인터페이스 스타일이다.
    안드로이드 플랫폼, IOS 플랫폼 등 특정 언어나 플랫폼에 종속되지 않고 사용이 가능하다.
  2. Stateless (상태 정보 유지 안함)
    Rest는 상태 정보를 유지하지 않는다.
    서버는 각각의 요청을 완전히 다른 것으로 인식하고 처리를 한다.
    이전 요청이 다음 요청 처리에 연관이 되면 안된다.
  3. Cacheable (캐시 가능)
    HTTP의 기존 웹 표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능 적용이 가능하다.
  4. Self-descriptiveness (자체 표현 구조)
    Rest API 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.
  5. Client-Server
    Rest 서버는 API 제공을 하고 클라이언트는 사용자 인증에 관련된 일들을 직접 관리한다.
    자원이 있는 쪽을 Server라고 하고 자원을 요청하는 쪽이 Client가 된다.
    서로간의 의존성이 줄어들기 때문에 역할이 확실하게 구분되어 개발해야할 내용들이 명확해진다.
  6. Layerd System (계층화)
    클라이언트는 Rest API 서버만 호출한다.
    Rest 서버는 다중 계층으로 구성될수 있으면 로드 밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의
    유연성을 둘 수 있다.

RESTFUL의 목적은 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이다.

user들을 표시 GET /users
user 하나만 표시 GET /users/:id
user를 생성 POST /users
user를 수정 PUT /users:id
user를 삭제 DELETE /users:id

CRUDHTTP METHOD URI

  • Restful 하지 못한 경우
  • CRUD 기능을 전부 POST METHOD로만 처리하는 API
  • URI에 자원과 id외 정보가 들어가는 경우 PUT /users/update-nickname [X] PUT /users/:id/nickname [O]

장점 (Positive Effect)

1. Easy to use (쉬운 사용)

REST API의 가장 큰 장점이라고 할 수 있습니다. 단순히 REST API 메시지를 읽는 것 만으로도 메시지가 의도하는 바를 명확하게 파악할 수 있죠. 굳이 해당 메시지의 기능이 무엇인지 알기 위해 메뉴얼을 하나씩 읽어 볼 필요가 없게 만들어 줍니다. 정리하면 엄청난 가독성이죠.

또한 HTTP 인프라를 그대로 사용하기 때문에, REST API 사용을 위한 별도의 인프라 구축을 요구하지 않습니다. 그리고 Stateless한 특징 때문에 수행 문맥(Execution Context)가 독립적으로 진행됨으로써 이전에 서버(호스트)에서 진행된 내용들에 대해 클라이언트가 알 필요가 없으며, 이제까지 진행된 히스토리에 대해서도 알 필요가 없게 됩니다. 즉 해당 URI와 원하는 메소드 자체만 독립적으로 이해하면 되죠.

 

2. Complete Seperation between Client and Server

클라이언트는 REST API를 이용하여 서버와 정보를 주고 받습니다. 위에서 언급한 Stateless 한 특징에 따라, 서버는 클라이언트의 문맥을 유지할 필요가 없게 됩니다.

결국 클라이언트와 서버는 ‘니들 일은 니들이 알아서 해’ 식으로 동작하게 됩니다. 서로에게 무관심한 이기적인 상황이라고 느껴지시나요? 하지만 실제로는 각자의 역할이 명확하게 분리되어 있다는 의미로 보는게 더 맞습니다. 

이러한 장점은 단순히 업무량 감소를 넘어 플랫폼의 독립성 확장이라는 효과를 가져올 수도 있는데요, HTTP 프로토콜 서비스라는 기본적인 요구만 충족되면 다양한 플랫폼에서 원하는 서비스를 쉽고 빠르게 개발하고 배포할 수 있게 됩니다. 리눅스 웹 서버에서 윈도우 플랫폼 기반의 웹 브라우저를 순식간에 동작시킬 수 있다는 말이죠. 어썸(Awesome)하죠?

 

3. Detail expression for specific data type

REST API는 헤더 부분에 URI 처리 메소드를 명시함으로써, 필요한 실제 데이터를 페이로드(바디)에 표현할 수 있도록 구성할 수 있는 기능을 제공합니다. 이는 특정 메소드의 세부적인 표현 문구를 JSON, XML 등 다양한 언어를 이용하여 작성할 수 있다는 장점 뿐만 아니라, 간결한 헤더 표현을 통한 가독성 향상이라는 두마리 토끼를 잡는 효과를 가져다 주게 되죠. 

 

단점 (Negative Effect)

1. Restriction of HTTP Method

REST API는 HTTP 메소드를 사용하여 URI를 표현합니다. 이러한 표현 방법은 다양한 인프라에서도 편리하게 사용할 수 있다는 장점을 주지만, 또 한편으로는 메소드 형태가 제한적 이라는 문제점을 가져오기도 합니다.

물론 내부 Context를 이용할 수 있습니다. 하지만 이 방법이 모든 부분에서 해결책을 제공하지는 못합니다. 예를 들어, 메일을 보내는 기능을 작성한다고 합시다. 단순히 보내는 기능 외에도 누구한테, 얼마나 많이, 시간을 예약해서 등 다양한 세부 기능들 또한 작성해야하는데, 이러한 여러 기능들을 구현하는데 제약이 발생할 수 있겠죠.

 

2. Absence of Standard (표준의 부재)

REST API의 가장 큰 단점이라고 할 수 있는데, 바로 표준이 존재하지 않습니다… (다르게 표현하면 입김 센 놈이 장 땡) 이는 관리의 어려움과 좋은(공식화 된) API 디자인 가이드가 존재하지 않음을 의미하는데요, 결국 REST API는 많은 사람들이 하나씩 쌓아올리는 ‘정당화 된 약속들’ 로 구성되고 움직이게 됩니다. 

이 부분에 대해 어떤 사람들은 ‘확장성과 발전 가능성’을 이야기합니다만, 표준의 유무는 기대감과 별도로 매우 중요한 요소입니다. 국내에도 이런 광고가 있었죠, ‘모두가 YES라고 할 때, NO라고 할 수 있는 사람’. 누군가에게는 표준의 중요성이 절실할 수 있습니다.

참고: wallees.wordpress.com/2018/04/19/rest-api-%EC%9E%A5%EB%8B%A8%EC%A0%90/

2. session - cookie 방식과 토큰 방식의 차이점에 대해 이야기해보세요

1) cookie

서버가 클라이언트에 데이터를 저장할 수 있습니다.

쿠키는 서버에서 클라이언트에 데이터를 저장하는 방법으로 서버가 원한다면 서버는 클라이언트에서 쿠키를 이용하여 데이터를 가져올 수 있습니다.

즉, 단순히 서버에서 클라이언트에 쿠키를 전송하는 것만 의미하지 않고 클라이언트에서 서버로 쿠키를 전송하는 것도 포함됩니다.

사용자 선호, 테마 등 장시간 보존해야 하는 정보 저장에 적합. 로그인 상태 유지. 인증정보를 쿠키에 넣어서 저장하기도 함.

하지만 데이터를 저장한 이후 아무 때나 데이터를 가져올 수 없습니다.

데이터를 저장한 이후 특정 조건(아래의)들이 만족하는 경우에만 다시 가져올 수 있습니다.

 

 

2) Session

유저 인증정보는 더이상 쿠키에 담기지 않고 각각의 세션 객체에 저장됩니다. 따라서 로그인 이후 각각의 세션 객체에 해당 유저의 인증정보를 저장하는 로직이 필요합니다.

이렇게 유저 인증정보를 저장하고 나면, 서버는 매 요청마다 해당되는 세션 객체에 저장된 유저 인증정보를 바탕으로 유저정보 요청같은 인증이 필요한 요청이 이전에 인증된 유저의 요청인지 검증 할 수 있습니다.

쿠키를 통해서 유효한 세션 아이디가 서버에 전달되고, 세션 객체에 해당 세션 아이디에 유저의 인증정보가 존재한다면 서버는 해당 요청이 유저정보에 접근 가능하다고 판단합니다.

세션 아이디가 담긴 쿠키는 인터넷 탭을 닫으면 삭제되지만, 유효기간이 따로 정해져 있지 않습니다. 따라서 쿠키 안의 세션 아이디가 유출될 수 있으므로, 로그아웃 요청시 서버에서 세션을 파괴하는 과정이 반드시 필요합니다.

3) token

토큰은 유저 정보를 암호화한 상태로 담을 수 있고, 암호화 했기 때문에 클라이언트에 담을 수 있습니다.

토큰기반 인증 중 대표적인 JWT (JSON Web Token)

JWT의 종류

  1. Access Token
  2. Refresh Token

Access token은 보호된 정보들(유저의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한부여에 사용합니다. 클라이언트가 처음 인증을 받게 될 때(로그인시), access, refresh token 두가지를 다 받지만, 실제로 권한을 얻는데 사용하는 토큰은 access token 입니다.

access token에는 비교적 짧은 유효기간 을 주어 탈취 되더라도 오랫동안 사용할 수 없도록 하는것이 좋습니다.

Access token의 유효기간이 만료된다면 refresh token을 사용하여 새로운 access token을 발급 받습니다. 이때, 유저는 다시 로그인 할 필요가 없습니다.

 

유효기간이 긴 refresh token마저 악의적인 유저가 얻어낸다면 큰 문제가 될 것입니다. 상당히 오랜 기간동안 access token이 만료되면 다시 발급 받으며 유저에게 피해를 입힐 수 있기 때문이죠. 그렇기 때문에 유저의 편의보다 정보를 지키는 것이 더 중요한 웹사이트들은 refresh token을 사용하지 않는 곳이 많습니다.

 

토큰기반 인증의 장점

  1. Statelessness & Scalability (무상태성 & 확장성)
    • 서버는 클라이언트에 대한 정보를 저장할 필요 없습니다 (토큰 해독이 되는지만 판단합니다)
    • 클라이언트는 새로운 요청을 보낼때마다 토큰을 헤더에 포함시키면 됩니다
      • 서버를 여러개 가지고 있는 서비스라면 더더욱 빛을 발휘합니다 (같은 토큰으로 여러 서버에서 인증 가능)
  2. 안전하다
    • 암호화 한 토큰을 사용하고, 암호화 키를 노출 할 필요가 없기 때문에 안전합니다
  3. 어디서나 생성 가능하다
    • 토큰을 확인하는 서버가 토큰을 만들어야 하는 법이 없습니다
    • 토큰 생성용 서버를 만들거나, 다른 회사에서 토큰관련 작업을 맡기는 것 등 다양한 활용이 가능합니다
  4. 권한 부여에 용이하다
    • 토큰의 payload(내용물) 안에 어떤 정보에 접근 가능한지 정할 수 있습니다
      • ex) 서비스의 사진과 연락처 사용권한만 부여

3. server의 역할에 대해 이야기해보세요

www.puffinsolutions.com/2019/01/importance-server-business