Restful API
REST란 Representational State Transfer의 약자. 여기에 ~ful이란 형용사형 어미를 붙여 ~한 API라는 표현으로 사용됨. 즉, REST의 기본원칙을 성실히 진킨 서비스 디자인은 RESTful하다고 표현할 수 있음.
REST가 디자인패턴이다, 아키텍처이다 많은 이야기가 존재하는데, 하나의 아키텍처로 볼 수 있음. 좀 더 정확한 표현으로 말하자면 REST는 Resource Oriented Architecture이다. API 설계의 중심에 자원(Resource)가 있고, HTTP Method를 통해서 자원을 처리하도록 설계하는 것이다.
REST 6가지 원칙
- Uniform Interface
- Stateless
- Caching
- Client-Server
- Hierarchical System
- Code on Demand
RESTful 하게 API를 디자인 한다는 것은 무슨 의미?
1. "리소스"와 "행위"를 명시적이고 직관적으로 분리
- 리소스는 URI로 표현되는데 리소스가 가리키는 것은 명사로 표현되어야한다.
- 행위는 HTTP Method로 표현하고 GET, POST, PUT, PATCH, DELETE을 분명한 목적으로 사용한다.
2. Message는 Header와 Body를 명확하게 분리해서 사용
- Entity에 대한 내용은 Body에 담는다.
- 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전정보, 응답받고자하는 MIME 타입 등은 Header에 담는다.
- Header와 Body는 Http Header와 Http Body로 나눌 수도 있고, Http Body에 들어가는 json구조로 분리할 수도 있다.
3. API 버전을 관리한다.
- 환경은 항상 변하기 때문에 API signature가 변경될 수도 있음에 유의하자
- 특정 API를 변경할 때는 반드시 하위호환성을 보장해야한다.
4. 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.
- 브라우저는 form-data형식으로 submit을 보내고 서버에서는 json 형태로 보내는 식의 분리보다는 json으로 보내든, 둘다 form data 형식으로 보내든 하나로 통일한다.
- 다른 말로 표현하자면 URI가 플랫폼 중립적이어야한다.
장점?
- Open API 제공하기 쉬움
- 멀티플랫폼 (웹, 모바일 ...) 지원 및 연동이 용이
- 원하는 타입으로 데이터를 주고 받을 수 있음
- 기존 웹 인프라 (HTTP)를 그대로 사용할 수 있음
단점?
- 사용할 수 있는 메서드가 4가지 밖에 없음
- 분산환경에 부적합
- HTTP 통신 모델에 대해서만 지원
HTTP GET POST비교
둘다 HTTP 프로토콜을 이용해서 서버에 무엇인가 요청할 때 사용하는 방식
GET
HTTP Body없이 요청 데이터가 HTTP Header 부분에 URL이 담겨서 전송됨. 때문에 url상의 ?뒤에 데이터가 붙어 request를 보내게됨. 이러한 방식을 url이라는 공간에 담겨서 가기 때문에 전송할 수 있는 데이터의 크기가 제한적. 또 보안이 필요한 데이터에 대해서는 데이터가 그대로 url에 노출되므로 GET방식은 적절하지 않음
POST
POST 방식의 request는 HTTP Request Message의 Body부분에 데이터가 담겨서 전송됨. 때문에 바이너리 데이터를 요청하는 경우 POST 방식으로 보내야하는 것처럼 데이터 크기가 GET보다 크고 보안면에서 나음. 하지만 보안적 측면에서는 암호화를 하지 않는 이상 고만고만함 (어차피 요청 메시지 탈취해서 파싱하면 다 알 수 있음)
차이
GET은 가져오는것. 즉 서버의 데이터를 가져와서 보여준다. SELECT 적인 성향. 서버의 상태나 값을 변경하는 것은 아님
반면에 POST는 서버의 값이나 상태를 변경하거나 추가하기 위해 사용.
부수적인 차이점을 더 살펴보자면, GET 방식의 요청은 브라우저에 캐싱할 수 있음. 때문에 POST 방식으로 요청해야할 것을 보내는 데이터의 크기가 작고 보안적인 문제가 없다는 이유로 GET 방식으로 요청한다면, 기존에 캐싱되었던 데이터가 응답될 가능성이 존재.
TCP UDP
UDP
- 비연결형 프로토콜
- 비신뢰적인 프로토콜
- IP 데이터그램을 캡슐화하여 보내는 방법과 연결설정을 하지 않고 보내는 방법 제공
- UDP는 흐름제어, 오류제어, 또는 손상된 세그먼트 수신에 대한 재전송을 하지 않음
- UDP가 행하는 것은 포트들을 사용하여 IP 프로토콜에 인터페이스를 제공하는 것
TCP
대부분의 인터넷 응용 분야들은 신뢰성과 순차적인 전달을 필요로함. UDP로는 이를 만족시킬 수 없음. TCP는 신뢰성이 없는 인터넷을 통해 종단간에 신뢰성있는 바이트 스트림을 전송하도록 특별히 설계됨. TCP는 서비스 송신자와 수신자 모두가 "소켓이라고 부르는 종단점"을 생성함으로써 이루어짐. TCP에서 연결설정은 3 way handshake를 통해 행해진다.
모든 TCP연결은 전이중, 점대점 방식이다 (full duplex, point to point) 전이중이란 전송이 양방향으로 동시에 일어날 수 있음을 의미하며, 점대점이란 각 연결이 정확히 2개의 종단점을 가지고 있음을 의미한다. TCP는 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.
HTTP vs HTTPS
- HTTP는 평문이기 때문에 도청 가능
- 통신상태를 확인하지 않기 때문에 위장 가능
- 완전성을 증명할 수 없기 때문에 변조 가능
위 세가지는 다른 암호화되지 않는 프로토콜에도 공통적으로 적용되는 문제점
TCP/IP는 도청 가능한 네트워크
TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있음. 패킷을 수집하는 것만으로 도청 가능. 평문으로 통신할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야함
보완방법
- 통신 자체를 암호화 SSL or TLS 라는 다른 프로토콜을 조합함으로서 HTTP 통신 내용을 암호화할 수 있음. SSL을 조합한 HTTP를 HTTPS라고 한다.
- 콘텐츠를 암호화, 말 그대로 HTTP를 사용해서 운반하느 내용인 HTTP 메시지에 포함되는 컨텐츠만 암호화 처리하는 것. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요
통신상대 확인하지 않기 때문에 위장 가능
- 리퀘스트를 보낸쪽이 웹서버가 원래 의도한 리스폰스를 보내야하는 곳인지 확인할 수 없음
- 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지 확인 불가
- 통신하고 있는 상대가 접근이 허가된 상대인지 확인 불가
- 어디에서 누가 리퀘스트했는지 확인 불가
- 의미없는 리퀘스트도 수신 -> DoS 공격 방지 불가
보완 방법
SSL로 상대 확인 가능. SSL은 상대를 확인하는 수단으로 "증명서"제공. 증명서는 신뢰할 수 있는 제 3자 기관 (CA기관)에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자하는 서버임을 나타내고, 이용자는 개인정보 누설 등의 위험성이 줄어들게 됨. 한가지 이점을 더 꼽자면 클라이언트는이 증명서로 본인확인을 하고 웹사이트 인증에서도 이용가능
완전성을 증명할 수 없기 때문에 메시지 변조 가능
완전성이란 정보의 정확성을 의미. 서버또는 클라이언트에서 수신한 내용이 송신측에서 전송한 내용과 일치한다는 것을 보장할 수 없음. 리퀘스트나 리스폰스가 발신된 후에 누군가에 의해 변조되더라도 이 사실을 알 수 없음. 이와 같이 공격자가 도중에 요청 응답을 빼앗아 변조하는 공격을 중간자 공격이라고 부름
보완 방법
MD5, SHA-1 등의 해시값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재. 하지만 확실히 확인할 수 있는 것은 아님. 확실히 방지하기 위해선 HTTPS 사용해야함. SSL에는 인증이나 암호화 그리고 다이제스트 기능 제공
HTTPS
HTTS는 SSL 껍질을 뒤집어쓴 HTTP 라고 할 수 있음. 새로운 응용 프로토콜 아님. HTTP 통신하는 소켓부분을 SSL 프로토콜로 대체하는 것 뿐. 원래 HTTP는 TCP와 직접 통신했지만, HTTPS에서는 SSL과 통신하고, SSL이 TCP와 통신하게 됨. SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있게됨.
HTTPS의 SSL에서는 대칭키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용. 대칭키를 공개키 방식으로 교환한 후 다음부터 통신은 대칭키를 이용하여 하는 방식.
공개키 암호화 : 공개키 비밀키 두가지 존재
대칭키 암호화 : 하나의 대칭키만 존재
모든 웹페이지에서 HTTPS 사용해도 될까?
평문 통신에 비해 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한대당 처리할 수 있는 리퀘스트 수가 상대적으로 줄어듬.
하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도저하가 거의 일어나지 않는다. 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰때만 HTTPS 암호화 통신을 사용하는 방식에서 현재 모든 웹페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고있다.
OSI 7계층
- 프로토콜을 기능별로 나눈 것
- 각 계층은 하위 계층의 기능만을 이용하고, 상위 계층에게 기능을 제공한다.
- 프로토콜 스택 혹은 스택은 이러한 계층들로 구성되는 프로토콜 시스템이 구현된 시스템을 가리킴. 프로토콜 스택은 하드웨어나 소프트웨어 혹은 둘의 조합으로 구현될 수 있음
- 일반적으로 하위 계층들은 하드웨어로, 상위계층들은 소프트웨어로 구현됨
