01. HTTP와 HTTPS
💡 HTTP/HTTPS는 어플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다.
① HTTP
HTTP는 서버와 클라이언트가 데이터를 주고 받기 위한 웹 통신규약(프로토콜)
HTTP는 암호화가 되지않은 데이터를 전송하는 프로토콜로, HTTP 프로토콜을 통해 개인 정보를 주고 받으면 제 3자가 이를 탈취할 수 있다.
이러한 문제를 해결하기 위해 HTTPS 가 등장하게 되었다.
② HTTPS
HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜로, 정보를 암호화하는 SSL 프로토콜을 통해 HTTP 요청 및 응답을 암호화한다.
정리하자면,
👉 HTTP는 서버와 클라이언트가 데이터를 주고 받기 위한 프로토콜이고, HTTPS는 HTTP보다 안전한 프로토콜이다.
👉 따라서 개인정보와 같은 민감한 데이터를 다뤄야할 땐 HTTPS 사용이 권장된다.
📌 HTTPS의 암호화 방식(SSL 프로토콜)
HTTPS는 공개키 암호화 방식을 통해 암호화가 이루어진다.
여기서 공개키 암호화 방식이란 공개키, 개인키라고 부르는 두 개의 키를 사용해 각각의 키는 암호화, 복호화만 가능하도록 제한을 둔 방식을 말한다.
즉 암호화한 내용을 풀려면 반드시 암호화에 사용되지 않은 키로만 복호화가 가능한 셈이다.
- 장점 : 암호화한 데이터가 탈취 당해도 비밀 키가 없다면 복호화할 수 없어, 보완성이 뛰어남.
- 단점 : 동일키로 암호화/복호화를 하는
대칭키 방식보다 복잡한 연산과정을 거치므로, 더 많은 연산 시간이 요구된다.
📌 HTTPS 통신 방법
HTTPS 통신은 인증서를 발급해주는 공인기관인 CA를 통해 클라이언트가 서버를 신뢰하고, 데이터를 암호화하는 과정으로 이루어진다.
- 서버는 HTTPS를 적용하기 위해 공개키와 개인키를 만든 후, 공개키 저장소인 CA와 계약하여 공개키를 보내 인증서 발급을 요청한다.
- CA는 CA기업의 이름과 서버 정보, 서버의 공개키 정보를 담은 인증서를 CA기업의 개인키로 암호화하여 서버에게 발급한다.
- 서버는 클라이언트 요청 시, CA에게 전달받은 암호화된 인증서를 클라이언트에게 전달한다.
- 클라이언트는 CA기업의 공개키로 인증서를 복호화하여 서버의 공개 키를 얻는다.
- 이때 모든 브라우저는 공인된 CA기업의 리스트와 해당 기업의 공개 키 정보를 보유하고 있다.
- 클라이언트는 이후 해당 서버와 통신할 때 서버의 공개키로 암호화하여 요청을 보낸다.
- 서버는 해당 요청을 서버의 개인키로 복호화하여 확인하므로, 서버와 클라이언트는 더욱 안전하게 데이터를 주고 받을 수 있다.
02. RESTful API
📌 RESTful API란
RESTful API는 HTTP 프로토콜을 기반으로 REST 설계 규칙을 준수한 API를 말한다. 즉 HTTP 프로토콜을 그대로 활용하기 때문에, 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
RESTful API의 가장 큰 특징으로는
❶ 각 요청만 보고도 어떤 동작이나 정보를 위한 것인지 쉽게 유추할 수 있고,
❷ 1개의 URI로 CRUD와 같은 4가지 행위를 명시할 수 있어 자원을 아낄 수 있다.
📍 REST란 무엇을 의미하는가❓
- 자원을 URI로 표시하고 해당 자원의 상태를 주고 받는 것을 의미한다.
- 좀 더 풀어서 설명해보면 👉 웹의 관점에서 REST는 URI를 통해 자원을 명시하고, 자원에 대한 행위는 HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것이다.
📍 REST API와 RESTful API는 무엇이 다를까❓
RESTful은 REST의 설계 규칙을 잘 지켜서 설계된 API를 의미한다.
👉 즉, REST의 원리를 잘 따르는 시스템(API)을 RESTful하다(RESTful API)고 할 수 있다.
📍 REST API 구성
- 자원(Resource) : URI(Uniform Resource Identifier)
- 행위(Verb): HTTP Method
- 표현(Representations) : 페이로드로, 서버와 클라이언트가 JSON 혹은 XML형태의 데이터로 주고 받는다.
📌 REST 설계규칙
- URI는 리소스를 표현해야 한다. 리소스를 식별할 수 있는 이름은 동사보다는 명사를 사용한다.
- 리소스에 대한 행위는 HTTP 요청 메서드로 표현한다. HTTP 메서드(GET, POST, PUT, PATCH, DELETE 등)를 사용하여 CRUD를 구현한다.
❶ URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.
// Bad
http://naver.com/Running/
// Good
http://naver.com/run/❷ 마지막에 슬래시 (/)를 포함하지 않는다.
// Bad
http://naver.com/test/
// Good
http://naver.com/test❸ 언더바 대신 하이폰을 사용한다.
// Bad
http://naver.com/test_blog
// Good
http://naver.com/test-blog❹ 파일 확장자는 URI에 포함하지 않는다.
// Bad
http://naver.com/photo.jpg
// Good
http://naver.com/photo❺ 행위를 포함하지 않는다.
// Bad
http://naver.com/delete-post/1
// Good
http://naver.com/post/1📌 HTTP Method
대표적인 HTTP Method로는 GET, POST, PUT, PATCH, DELETE가 있다.
| Method | 역할 | 설명 |
|---|---|---|
| GET | READ | 서버에게 URI가 가진 정보 검색 요청 |
| POST | CREATE | 서버에게 추가할 정보 보냄 |
| PUT | UPDATE | 주로 데이터 전체를 바꿀 때 사용 |
| PATCH | UPDATE | 주로 일부 데이터만 수정할 때 사용 |
| DELETE | DELETE | 특정 정보 삭제 |
03. URI
📌 URI의 구조
- sheme(스키마) : 리소스를 얻기위해 사용할 프로토콜을 의미하며, 웹에서는 주로 HTTP또는 HTTPS를 사용
- host(domain) : 접근할 서버의 도메인(호스트명) 또는 IP주소
- port : 접근할 서버의 네트워크 포트번호 / 생략시 디폴트 포트가 사용됨(Http인 경우 : 80, Https인 경우 : 443)
- path : 접근할 서버 경로에 대한 상제 정보
- query : 접근할 서버에 전달할 추가적인 정보(key-value형식)
- fragment : 서브 리소스에 접근할 때 식별하기 위한 정보 (세부 주제를 찾을 때)
📍 URI vs URL
URI는 URL을 포괄하는 상위 개념이다.
- URL은 흔히 '웹주소'라고도 하며, 인터넷 네트워크 상 자원의 위치를 의미한 다.
- URI는 자원을 식별할 수 있는 문자열의 구성, 즉 식별자를 가리킨다.
👉 따라서 URI와 URL의 차이점은 URI는 자원을 식별하고, URL은 자원의 위치를 가르킨다라고 할 수 있다.
