HTTP와 HTTPS의 차이점
HTTP 와 HTTPS의 가장 큰 차이점은 보안성이다. 자세히 알아가기 전 프로토콜에 대해 먼저 알아보았다.
프로토콜 (Protocol)
표준 국어 대사전
프로토콜(protocol)은 컴퓨터와 컴퓨터 사이, 또는 한 장치와 다른 장치 사이에서 데이터를 원활히 주고받기 위하여 약속한 여러 가지 규약(規約)"
서로 다른 컴퓨터들이 인터넷이라는 공간에서 원활히 데이터를 주고 받을 수 있도록 같은 프로토콜을 사용한다.
즉, 프로토콜은 네트워크에 연결된 컴퓨터 간에 정보를 주고받을 때 지키기로 한 약속 이다.
그런 약속 중에서도 표준이 필요한데 우리는 대부분 TCP/IP 프로토콜을 사용하고 있다.
TCP/IP
TCP 프로토콜은 네트워크의 혼잡도 등을 고려해 데이터의 흐름을 제어하고 데이터가 정확히 도착할 수 있게 하는 절차와 방법을 정한 프로토콜이다.
그 밖에도 데이터를 전송하는 목적에 따라 다양한 프로토콜이 있는데, 웹 브라우저로 웹 사이트에 접속할 경우 HTTP 와 HTTPS 프로토콜이 사용된다.
TCP/IP 와 HTTP 관계
정리하면, 컴퓨터 운영체제가 TCP 와 IP 에 따라 프로그래밍 되어 있기 때문에 인터넷 연결이 가능하고, 웹 프라우저가 HTTP(또는 HTTPS) 에 따라 프로그래밍 돼어 웹 사이트 접속이 가능한 것이다.
출처
프로토콜 뜻
HTTP란?
웹에서 브러우저와 서버간 데이터를 주고받기 위한 방식
HTTP 특징
HTTP 는 상태가 없는(stateless) 프로토콜이다.
상태가 없다는 말은 데이터를 주고 받기 위한 각각의 데이터 요청이 서로 독립적으로 관리 된다는 말이다. 쉽게 말해 이전 데이터 요청과 다음 데이터 요청이 서로 관련이 없다는 말
이러한 특징 덕에 서버는 세션과 별도의 추가 정보를 관리하지 않아도 되고, 다수의 요청 및 서버의 부하를 줄일수 있는 성능 상 이점이 생긴다.
HTTP 는 일반적으로 TCP/IP 통신 위에 동작하고 기본 포트는 80번이다.
HTTP Request & HTTP Response
HTTP 프로토콜로 데이터를 주고받기 위해서는 아래와 같이 요청(Request)을 보내고 응답(Response)을 받아야 한다.
URL(Uniform Resource Locators)
버에 자원을 요청하기 위해 입력하는 영문 주소
HTTP 요청 메서드
- GET : 존재하는 자원에 대한 요청
- POST : 새로운 자원을 생성
- PUT : 존재하는 자원에 대한 변경
- DELETE : 존재하는 자원에 대한 삭제
기타 요청 메서드
- HEAD : 서버 헤더 정보를 획득. GET과 비슷하나 Response Body를 반환하지 않음
- OPTIONS : 서버 옵션들을 확인하기 위한 요청. CORS에서 사용
HTTP 상태코드
상태 코드를 통해 페이지가 정상적인 접근이 이루어지는 지에 대한 여부를 알 수 있다.
클라이언트가 보낸 HTTP 요청에 대한 서버의 응답코드로 성공/실패 여부를 알 수 있다.
상태코드와 SEO(검색엔진 최적화) 측면에서 바라보는 상태코드는 나중에 따로 정리해보자.
HTTPS란?
HTTP 는 정보를 텍스트로 주고 받기 때문에 네트워크에서 전송 신호를 받을 때, 데이터 유출이 발생할 수 이 있다.
이러한 보안 취약점을 해결하기 위해 HTTP 에서 S(Secure Socket)이 추가 된 HTTPS 이다.
왜 HTTPS 를 써야해?
구글은 HTTPS 를 사용하는 웹사이트에 대해 검색 순위 결과에 약간의 가산점을 주겠다고 HTTP 를 HTTPS 로 바꾸라고 권고했다. 이에 그치지 않고 2019년, 구글은 크롬 68을 릴리즈하며 7월부터 SSL 보안 서버가 적용된 HTTPS 웹페이지는 ‘안전함’으로 표시하고 그렇지 않은 HTTP 사이트에 대해서는 ‘안전하지 않음’ 경고 표시를 적용할 것이라고 발표했다.
HTTP , HTTPS 차이점
HTTPS와 기본 골격은 동일하지만, 데이터를 주고 받는 과정에서 '보안' 요소가 추가된 것이 가장 큰 차이점!
HTTPS를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화 된다.
동작방식과 장단점은 나중에 따로 정리해보자.
추천 도서
HTTP 완벽 가이드 - 일명 다람쥐 책
RESTful API
프로젝트 중 API 명세서를 쓸 때, 머리속에 항상 생각되는건 RESTful 하게 설계 였다.
그 때는 그저 url 주소에 get, post 같은 메서드를 넣지 않고, 누가 봐도 user 에 대한 api 라는걸 유추 할 수 있도록 명시를 해주는 것이라고만 생각했다.
이번 기회에 RESTful API 에 대해 알아보자.
- 한국어로 번역도 잘 되어있다.
API 란?
Application Programming Interface(애플리케이션 프로그램 인터페이스)의 줄임말
다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의한다. 일반적인 규칙들을 알아보았다.
-
요청 메서드: 요청의 목적을 나타내기 위해 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용
-
엔드포인트: API 서버에 요청을 보낼 때 요청할 리소스의 URL을 지정
-
인증: API 서버에 접근하기 위해서는 보안상의 이유로 API 키 또는 인증 토큰 등의 인증 정보가 필요 수 있다.
-
요청 본문: POST, PUT 등의 HTTP 메서드를 사용하는 경우, 요청 본문에 데이터를 전송할 수 있다. 이때 데이터의 형식은 일반적으로 JSON, XML, HTML 등이 사용
-
응답: API 서버는 요청에 대한 응답으로 HTTP 상태 코드와 함께 요청 결과를 반환
-
오류 처리: API 서버는 요청에 대한 처리 과정에서 오류가 발생할 수 있다. 이때는 HTTP 상태 코드를 이용해 오류를 알리고, 오류 메시지를 반환
리소스(Resource) = 자원
리소스는 다양한 애플리케이션이 클라이언트에게 제공하는 정보이며, 예를들어 이미지, 동영상, 텍스트, 숫자 또는 모든 유형의 데이터일 수 있다.
클라이언트에 리소스를 제공하는 시스템을 서버라고도 한다.우리는 API를 사용하여 리소스를 공유하고 보안, 제어 및 인증을 유지하면서 웹 서비스를 제공한다.
REST 란?
REST는 Representational State Transfer의 줄임말이다.
Representational 어원과 뜻
Representational의 어원은 Represent라는 단어입니다. Represent는 '나타내다', '상징하다', '대표하다' 등의 의미를 가지며, 여기에 -ational 접미사가 붙어 '나타내는', '상징적인', '대표적인' 등의 의미를 가지게 됩니다.
따라서 Representational의 전체적인 의미는 '상태를 나타내는' 또는 '자원을 대표하는' 정도로 이해할 수 있습니다. REST 아키텍처에서는 각 자원의 상태를 URL을 통해 나타내고, 이를 대표하는 Representation을 주고 받으므로, Representational이라는 용어가 사용되었습니다.
-ChatGPT
즉, 자원의 상태를 주고 받는 모든 것을 의미한다.
또 , AWS 에서는 REST 를 이렇게 정의했다.
epresentational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처 이다.
REST API 란
다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의하는 API 에 조건을 부과하는 아키텍처란 의미이다.
결국 내가 이해했을땐 API 만들 때, 우리가 규칙을 정했으니 규칙(REST)에 따라 깔끔하게 만들어라 라는 뜻 같다.
이렇게 REST 아키텍처 스타일을 따르는 API 를 REST API 라고 하고, REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 한다.
RESTful API라는 용어는 일반적으로 RESTful 웹 API를 나타냅니다. 하지만 REST API와 RESTful API라는 용어는 같은 의미로 사용할 수 있습니다.
- AWS
REST 아키텍처 스타일 원칙
아래는 REST 아키텍처 스타일의 몇 가지 원칙을 소개한다.
1. 균일한 인터페이스
a. 균일한 리소스 식별자를 사용해라.
예를들어 유저에 대한 URL 은 /user
유저 상세 조회는 /user/{id}
b. 클라이언트는 원하는 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현해라
수정이나 삭제를 하고 싶다면, 클라이언트는 URL을 사용하여 서버에서 특정 리소스를 식별하고 요청할 수 있다. (예를들어, 파람이나 쿼리를 활용해 내가 원하는 리소스를 요청 및 수정 삭제)
그리고 해당 정보를 리소스 표현 형식(JSON 등) 에 포함 될 수 있다.
c. 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메세지를 전송해야한다.
문서로는 API 명세서로 기술 할 수도 있고,
응답 메세지인 HTTP 상태코드 와 HTTP 요청 메세지에 사용되는 헤더(Header) 를 명확히 보내라는 뜻.
d. 클라이언트가 더 많은 리로스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송한다.
REST 아키텍처에서 하이퍼링크(Hyperlink)를 사용하여 클라이언트와 서버 간의 상호작용을 촉진하는 방법 중 하나
해당 방법 중 하나는, HATEOAS(하이퍼미디어를 이용한 분산시스템의 상호운용성)를 지원하는 RESTful API를 설계하는 것인데.. 해당 내용은 처음 들어본다.
REST, REST API, RESTful 과 HATEOAS
해당 블로그는 HATEOAS 를 찾아보다 알게 된 정리본
나는 하루종일 걸려서 찾고 예시찾아보고 했는데 마치 아무것도 아닌 듯 물결 흐르듯 설명이 잘 되어 있다.. 보고 좀더 공부해야겠다.
이 밖에도 URL 를 자원으로 표현할 때 동사보다 명사, 대문자보다 소문자 이용, 마지막 슬래시 이용하지 말기, 언더바 대신 하이픈 이용하기 등 여러가지가 있다.
API 의 설계에 있어 RESTful API은 당연히 해야하지만 대충 알고 넘겨 이렇게 자세히 알아본적은 없었다.
해당 부분은 좀더 공부할 필요가 있어보인다.
