[13일차] REST API & HTTPS

https://ko.wikipedia.org/wiki/HTTP

 

REST API란?

•  - 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식을 말한다
•  - 클라이언트 요청이 RESTful API를 통해 이루어지면 리소스 상태 표현을 요청자 또는 끝점으로 전송다. 이 정보 또는 표현은 HTTP를 통해 JSON(Javascript Object Notation), HTML, XLT, Python, PHP 또는 일반 텍스트와 같은 여러 형식 중 하나로 전달된다.
•  - 헤더와 매개변수는 RESTful API HTTP 요청의 HTTP 메서드에서도 중요하다. 요청의 메타데이터, 권한 부여, URI(Uniform Resource Identifier), 캐싱, 쿠키 및 더. 요청 헤더와 응답 헤더가 있으며 각각 고유한 HTTP 연결 정보와 상태 코드가 있다.

 

좋은 REST API를 디자인하기 위한 4단계 모델

 

• 0단계:
  •  - 단순히 HTTP 프로토콜을 사용하기만 해도 된다.
  •  - 해당 API를 REST API라고 할 수는 없으며, 0단계는 좋은 REST API를 작성하기 위한 기본 단계이다
  •  - 단순히 HTTP 프로토콜을 사용하는 것이 REST API의 출발점이다.

 

• 1단계
  •  - 1단계에서는 개별 리소스와의 통신을 준수해야 한다
  •  - 모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야 한다
  •  - 요청하고 받은 자원에 대한 정보를 응답으로 전달해야 한다는 것이 1단계에서 의미이다
  • 0단계에서는 모든 요청에서 엔드포인트로 /appointment를 사용했다, 하지만 1단계에서는 요청하는 리소스가 무엇인지에 따라 각기 다른 엔드포인트로 구분해서 사용해야 한다

• 예약 가능한 시간 확인이라는 요청의 응답으로 받게 되는 자원(리소스)은 허준이라는 의사의 예약 가능한 시간대이다. 그렇기 때문에 요청 시 /doctors/허준이라는 엔드포인트를 사용한 것을 볼 수 있다.
• 특정 시간에 예약하게 되면, 실제 slot이라는 리소스의 123이라는 id를 가진 리소스가 변경되기 때문에, 하단의 특정 시간에 예약이라는 요청에서는 /slots/123으로 실제 변경되는 리소스를 엔드포인트로 사용한다.
• 어떤 리소스를 변화시키는지 혹은 어떤 응답이 제공되는지에 따라 각기 다른 엔드포인트를 사용하기 때문에, 적절한 엔드포인트를 작성하는 것이 중요하다.
• 동사, HTTP 메소드, 혹은 어떤 행위에 대한 단어 사용은 지양하고, 리소스에 집중해 명사 형태의 단어로 작성하는 것이 바람직하다

 

• 요청에 따른 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공/실패 여부를 반환해야 한다.
•  예를 들어 만약 김코딩 환자가 허준 의사에게 9시에 예약을 진행하였으나, 해당 시간이 마감되어 예약이 불가능할 때실패 여부를 포함한 응답을 받아야 한다.

 

• 2단계
  •  - 2단계에서는 CRUD에 맞게 적절한 HTTP 메소드를 사용하는 것에 중점을 둔다.
  • 예약 가능한 시간을 확인한다는 것은 예약 가능한 시간을 조회(READ)하는 행위를 의미하고, 특정 시간에 예약한다는 것은 해당 특정 시간에 예약을 생성(CREATE)한다는 것과 같다.
  • 조회(READ)하기 위해서는 GET 메소드를 사용하여 요청을 보내고, 이때 GET 메소드는 body를 가지지 않기 때문에 query parameter를 사용하여 필요한 리소스를 전달한다.
  •  - 예약을 생성(CREATE)하기 위해서는 POST 메소드를 사용하여 요청을 보내야 한다.
  •  - 2단계에서는 POST 요청에 대한 응답이 어떻게 반환되는지도 중요합니다.

• 이 경우 응답은 새롭게 생성된 리소스를 보내주기 때문에, 응답 코드도 201 Created 로 명확하게 작성해야 하며, 관련 리소스를 클라이언트가 Location 헤더에 작성된 URI를 통해 확인 할 수 있도록 해야, 완벽하게 REST 성숙도 모델의 2단계를 충족한 것이라고 볼 수 있다.

 

• 메소드를 사용할 때 규칙
  • GET 메소드는 서버의 데이터를 변화시키지 않는 요청에 사용해야 한다.
  • POST는 요청마다 새로운 리소스를 생성하고 PUT은 요청마다 같은 리소스를 반환한다.
  • 이렇게 매 요청마다 같은 리소스를 반환하는 특징을 멱등(idempotent)하다고 한다.
  • 멱등성을 가지는 메소드 PUT과 그렇지 않은 POST는 구분하여 사용해야 한다.
  • PUT은 교체, PATCH는 수정의 용도로 사용한다
  • REST 성숙도 모델의 3단계까지 적용한 경우는 극히 드물며 3단계까지 무조건적으로 모두 적용해야 한는 것은 아니다

 

• 3단계
  • 하이퍼미디어 컨트롤을 적용한다
  • 3단계의 요청은 2단계와 동일하지만, 응답은 리소스의 URI를 포함한 링크 요소를 삽입하여 작성하는 것이 다르다

•  허준이라는 의사의 예약 가능 시간을 확인한 후에는 그 시간대에 예약을 할 수 있는 링크를 삽입하거나, 특정 시간에 예약을 완료하고 나서는 그 예약을 다시 확인할 수 있도록 링크를 작성해 넣을 수도 있습니다. 이렇게 응답 내에 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 하는 것이 3단계의 중요 포인트이다

 

● 문제

요리 레시피를 제공하는 웹사이트를 만들기 위해, 냉장고에 있는 재료 목록을 조회해야 합니다. 엔드포인트로(endpoint)는 어떤 것이 적절할까요?

 

GET /refrigerator 도 얼핏 맞는 설명처럼 보이나, 결과적으로 응답에는 재료 목록이 전달됩니다. 엔드포인트는 어떻게 요청되는지, 혹은 어디로부터 나온 요청인지는 중요하지 않습니다. 어떤 응답이 제공되는가가 중요하므로, 가장 적절한 엔드포인트는 GET /ingredient 이다.

 

HTTPS란?

HTTP 요청을 SSL 혹은 TLS 알고리즘을 이용해, HTTP 통신을 하는 과정에서 내용을 암호화하여 데이터를 전송하는 방법

 

• 암호화 기본 개념
  •  - 어떤 정보를 아무나 읽지 못하도록 키를 가지고 특정 알고리즘을 돌려 정보를 숨기는 것 이다.
  •  - 키를 가지고 다시 알고리즘을 역행하면 복호화(decryption)가 된다.
  •  - 키가 없으면 암호화와 복호화를 하지 못하기 때문에 키는 굉장히 중요한 역할을 한다.

 

• 공개키(Public Key)와 비밀키(Private Key)
  • 모두가 볼 수 있는 키이며 비밀키는 소유자만이 가지고 있는 키로 암/복호화에 사용된다.
  • A키로 암호화를 하면 B키로 복호화를 할 수 있다.
  • B키로 암호화를 하면 A키로 복호화를 할 수 있다.
  • 둘 중 하나를 비공개키(Private Key) 혹은 개인키라 부르며, 이는 자신만 가지고 있고 공개되지 않는다.
  • 나머지 하나를 공개키(Public Key)라고 부르며 타인에게 제공한다. 공개키는 유출이 되어도 비공개키를 모르면 복호화 할 수 없기 때문에 안전하다.

 

• 비대칭키 암호화
  • 서버와 클라이언트가 암호화/복호화에 각각 다른 비밀키를 사용하는 방식이다.
  • 공개키를 통해서 암호화를 하고 비밀키를 통해서 복호화를 한다.
  • 공개키는 공개해도 상관없으니 키 관리에 어려움이 없으나, 속도가 느리다.

 

• 인증기관(Certificate Authority, CA)
  • CA)는 공개키와 공개 DNS명(ex.www.example.com)의 연결을 보장하는 기관이다.
  • 클라이언트가 접속을 요청한 서버가 의도한 서버가 맞는지 인증해주는 역할을 하는 보증된 기업들이다.
  • 클라이언트는 서버에 요청을 해서 CA가 발급한 인증서를 받은 뒤 CA의 공개키로 복호화하여 신뢰할 만한 인증서인지 검증한다.

 

• SSL 보안 소켓 계층(Secure Sockets Layer, SSL) 인증서
  • 디지털 인증서로 불리며, 브라우저(사용자의 컴퓨터)와 서버(웹사이트) 사이의 암호화된 연결을 수립하는 데 사용된다.
  • SSL 방식을 적용하려면 인증서를 발급받아 서버에 적용시켜야 한다.
  • 인증서는 사용자가 접속한 서버가 우리가 의도한 서버가 맞는지를 보장하는 역할을 한다.
  • 인증서를 발급하는 기관을 CA(Certificate Authority)라고 부른다.
  • 공인인증기관의 경우 웹 브라우저는 미리 CA 리스트와 함께 각 CA의 공개키를 알고 있다.
  • SSL은 대칭키 방식과 비대칭키 방식을 적절히 섞어서 사용하면서 신뢰도를 높인다.
  • 대칭키를 혼용하여 사용하는 이유는 비대칭키의 방식이 컴퓨터에 과부화를 주기 때문이다.

 

• TLS
  • Transport Layer Security의 줄임말.
  • SSL에서 발전하며 이름이 변경 된 것이다. 하지만 아직도 SSL이란 명칭이 많이 사용되고 있다.