HTTPS, RESTful

HTTPS

• 기존의 http사이트에 보안성을 추가함 ex) 로그인시 아이디와 비번을 입력하고 네이버 서버로 전송시 http로 요청시 제 3자가 정보를 볼 수 있었음

HTTPS역할

• https는 입력한 중요한 정보를 서버로 보낼때 보낸 정보를 암호화하여 서버로 전송하는 역할
• 데이터를 보내는 정보가 안전한 사이트로 전송되는지 확인하는 역할 = 사이트를 검증하는 역할

내가 사이트에 보내는 정보들을 제3자가 확인할 수 없도록함

• 대칭키 요청을 보내는 쪽과 받는 쪽이 같은 키를 가짐, 데이터 전송시 가지고 있는 키로 데이터 암호화 => 대칭키를 가지고 알고리즘 복호화하여 데이터 해석
• 대칭키를 제 3자가 확인하면 대칭키의 의미가 없어짐
• 비대칭키(공개키) A키로 암호화하면 B키로 복호화 , B키로 암호화하면 A키로 복호화
• 사용자는 네이버의 공개키를 가지고 있음
• CA에서 인증키를 발급받아 사용 , 브라우저에는 CA에서 발급한 공개키가 내장되어 있음

HTTPS 작동 과정

• HTTPS는 HTTP요청 및 응답을 SSL 및 TLS에 결합
• 사용자 브라우저 주소에 https://로 url 설정 후 서버에 요청
• 브라우저는 서버의 SSL 인증서를 요청하여 사이트의 신뢰성 검증시도 클라이언트 -> 서버
• 서버는 공개키(비대칭키) 가 포함된 SSL 인증서를 클라이언트로 전송 서버 -> 클라이언트
• 서버에서 전송된 인증서가 인증되면 브라우저가 공개키를 사용하여 세션키가 포함된 메세지를 암호화 하고 전송
• 서버는 프라이빗키를 사용하여 메세지를 해독하고 세션 키를 검색 => 세션키를 암호화하고 브라우저에 승인 메세지를 전송
• 브라우저와 웹서버 모두 동일한 세션 키를 사용하여 메세지를 안전하게 교환하도록 전환
• 여기까지 과정이 최초 https요청시 발생하는 과정 이후 서버와 주고받는 요청과 응답은 암호화 되어 제3자가 조회할 수 없음 최초 https 연결시에는 세션키공유 => 공개키 사용
• https 연결 이후에는 대칭키를 사용하여 데이터를 암호화 하고 복호화 하는 과정을 빠르게 수행

RESTful API

• REST스러운 API?
• 웹이 최초에 데이터를 주고 받는 형식은 각자가 쓰는 데이터 형식과 프로토콜이 각자다름
• 서버와 클라이언트 간의 결합도가 높아짐 => 서버의 변경이 클라이언트에 심각한 영향을 미침
• 기존 www는 서버와 클라이언트간의 결합도가 높음 => 표준 통신형식이 존재하지 않았음
• 자원을 어떻게 표현할지, 어떻게 관리할지 표준이 부재 ex) /new-user  => a  !==   /new/user  => b
• 한페이지 안의정보가 많아지고 복잡해져 자원관리가 어려워짐 => 페이지의 한부분만 변경해도 페이지 전체를 변경해야함 (html 파일을 다시 요청함)

WWW의 문제점

• 클라이언트와 서버 간 결합도가 높다
• 자원관리가 어렵다.

REST

• REST는 웹을 위한 제약조건의 집합을 의미

제약조건

• 클라이언트 - 서버구조 => 서버는 클라이언트로 데이터만 전송하면 끝
• 무상태성 => 요청은 상태를 가지지않음, 서버는 클라이언트가 이전에 무슨 요청을 보냈는지 모름
• 캐시가능성 => 서버는 자원이 캐시 가능한지 명시해야 한다는 제약조건 
• 계층형 시스템 => 계층형 시스템을 적용해야 한다는 제약조건
• 주문형 코드 => 필요에 의해 기능을 확장할 수 있도록 해야한다는 제약조건 가장 중요하면서도 지키기 어려움 ex) 플러그인
• *균일한 인터페이스 => 개발을 할 때 클라이언트와 맞닿아 있는 부분을 쉽고 일반적으로 설계하라는 제약조건
• *자원의 식별 => 
• *자기서술적 데이터 => html은 명세가 존재함, 해당 메세지를 해석하기 위한 방법이 존재한다는 것

요약

• www의 등장으로 전세계에서 웹이라는 공간을 통해 데이터를 주고 받을 수 있게됨 => 폭발적인 사용량 증가로 인해 몇가지 문제 발생 =>  문제 해결을 위해 REST 등장
• REST란 제약조건의 집합으로서 optional한 제약조건을 제외하고 5가지 이상의 제약조건을 모두 만족하면 RESTful하다라고 함
• 클라이언트 - 서버구조, 무상태성, 캐시 가능성, 계층형 시스템, 주문형 코드 *균일한 인터페이스
• 균일한 인터페이스 제약조건이 가장 지키기어려움
• 실제 대부분의 RESTful API를 작성하는 것은 어려움 개발비용 대비 기대효과가 낮고 제약조건이 많아 RESTful을 지키기 어려움