Skip to content

Latest commit

 

History

History
241 lines (159 loc) · 12.6 KB

httphttpsrestapi.md

File metadata and controls

241 lines (159 loc) · 12.6 KB

Http? Https? Rest Api?

HTTP란?

HyperText Transfer Protocol의 약자로써, 풀어서 설명하면
하이퍼텍스트(HyperText)를 전송(Transfer)하기 위해 사용되는 통신 규약(Protocol) 이다.

⇒ 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜이다.

즉, 인터넷에서 HTML과 같은 문서를 사용자 컴퓨터에 설치된 웹 브라우저가 웹 서버에 요청할 때의 규칙

HTTP 동작

클라이언트 즉, 사용자가 브라우저를 통해서 어떠한 서비스를 url을 통하거나 다른 것을 통해서 요청(request)을 하면
서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 응답(response)하는 형태로 동작한다.

요청 : client -> server

응답 : server -> client

HTML 문서만이 HTTP 통신을 위한 유일한 정보 문서는 아니다.

Plain text로 부터 JSON 데이터 및 XML과 같은 형태의 정보도 주고 받을 수 있으며,
보통은 클라이언트가 어떤 정보를 HTML 형태로 받고 싶은지, JSON 형태로 받고 싶은지 명시해주는 경우가 많다.

HTTP 특징

  • HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해 해석이 된다.
  • TCP/ IP를 이용하는 응용 프로토콜이다.(컴퓨터와 컴퓨터간에 데이터를 전송 할 수 있도록 하는 장치로 인터넷이라는 거대한 통신망을 통해 원하는 정보(데이터)를 주고 받는 기능을 이용하는 응용 프로토콜)
  • HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다.(이러한 단점을 해결하기 위해 Cookie와 Session이 등장하였다.)
  • HTTP는 연결을 유지하지 않는 프로토콜이기 때문에 요청/응답 방식으로 동작한다.

서버 : 어떠한 자료에 대한 접근을 관리하는 네트워크 상의 시스템 (요청에 대한 응답을 보내준다.)

클라이언트 : 그 자료에 접근할 수 있는 프로그램 ex) 웹 브라우저, 핸드폰 어플리케이션 등...

  • Request

    Request (요청)

    클라이언트가 서버에게 연락하는 것을 요청이라고 하며 요청을 보낼때는 요청에 대한 정보를 담아 서버로 보낸다.

    서버가 주문서를 받아 클라이언트가 어떤 것을 원하는지 파악할 수 있게 한다.
    이처럼 요청은 식당에서 주문서를 작성하는 것과 같다고 생각하면 된다.

    Request Method (요청의 종류)

    GET : 자료를 요청할 때 사용

    POST : 자료의 생성을 요청할 때 사용

    PUT : 자료의 수정을 요청할 때 사용

    DELETE : 자료의 삭제를 요청할 때 사용

    Request HTTP 메시지 예시

    GET https://velog.io/@surim014 HTTP/1.1								// 시작줄
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...			  // 헤더
Upgrade-Insecure-Requests: 1
    1. 시작줄 (첫 줄)

    첫 줄은 시작줄로 메서드 구조 버전으로 구성되었다.

    2. 헤더 (두 번째 줄부터)

    두번째 줄부터는 헤더이며 요청에 대한 정보를 담고 있다. User-Agent, Upgrade-Insecure-Requests 등등이 헤더에 해당되며 헤더의 종류는 매우 많다.

    3. 본문 (헤더에서 한 줄 띄고)

    본문은 요청을 할 때 함께 보낼 데이터를 담는 부분이다. 현재 예시에는 단순히 주소로만 요청을 보내고 있고 따로 데이터를 담아 보내지 않기 때문에 본문이 비어있다.

  • Response

    Response (응답)

    서버가 요청에 대한 답변을 클라이언트에게 보내는 것을 응답이라고 한다.

    Status Code (상태 코드)

    상태 코드에는 굉장히 많은 종류가 있다. 모두 숫자 세 자리로 이루어져 있으며, 아래와 같이 크게 다섯 부류로 나눌 수 있다.

    1XX (조건부 응답) : 요청을 받았으며 작업을 계속한다.

    2XX (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.

    3XX (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.

    4XX (요청 오류) : 클라이언트에 오류가 있음을 나타낸다.

    5XX (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.

    Response HTTP 메시지 예시

    HTTP/1.1 200 OK														// 시작줄
Connection: keep-alive												 // 헤더
Content-Encoding: gzip
Content-Length: 35653
Content-Type: text/html;

<!DOCTYPE html><html lang="ko" data-reactroot=""><head><title...
    1. 시작줄 (첫 줄)

    첫 줄은 버전 상태코드 상태메시지로 구성되어 있다. 200은 성공적인 요청이었다는 뜻이다.

    2. 헤더 (두 번째 줄부터)

    두 번째 줄부터는 헤더로 응답에 대한 정보를 담고 있다.

    3. 본문 (헤더 뒤부터)

    응답에는 대부분의 경우 본문이 있다. 보통 데이터를 요청하고 응답 메시지에는 요청한 데이터를 담아서 보내주기 때문이다. 응답 메시지에 HTML이 담겨 있는데 이 HTML을 받아 브라우저가 화면에 렌더링한다.

HTTP 서버는 기본 포트인 80번 포트에서 서비스 대기 중이며, 클라이언트(웹 브라우저)가 TCP 80 포트를 사용해 연결하면 서버는 요청에 응답하면서 자료를 전송한다.

HTTP는 정보를 텍스트로 주고 받기 때문에 네트워크에서 전송 신호를 인터셉트 하는 경우 원하지 않는 데이터 유출이 발생할 수 있다.

이러한 보안 취약점을 해결하기 위한 프로토콜이 HTTP에 S(Secure Socket)가 추가된 HTTPS이다.

HTTP에는 단점이 존재했는데 주고 받는 데이터가 전송될 때 암호화되지 않기 때문에 보안에 취약하다는 것.

이러한 문제를 해결하기 위해 중요한 정보를 주고 받을 때 도난당하는 것을 막게 하는 프로토콜(HTTPS)이 생성

HTTPS란?

기본 골격이나 사용 목적 등은 HTTP와 거의 동일하지만, 데이터를 주고 받는 과정에 ‘보안’ 요소가 추가되었다.

HTTPS를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화된다.

  • HTTPS는 페이지를 암호화한 키가 그 페이지를 보는 특정 사용자에게만 알려지도록 한다. HTTPS는 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화하며, 기본 TCP/IP 포트는 443이고, SSL 프로토콜 위에서 HTTPS 프로토콜이 동작한다.

동작 과정

서버 = 사이트, 클라이언트 = 사용자

HTTPS의 장단점

  • HTTPS는 웹사이트의 무결성을 보호해준다. 웹 사이트와 사용자 브라우저 사이의 통신을 침입자가 건드리지 못하도록 한다. (침입자라함은, 악의가 있는 공격자는 물론이고, 합법이지만 통신에 침입하여 페이지에 광고를 삽입하는 경우도 해당)
  • 가벼운 웹 서핑이라면 HTTP도 상관없지만, 사용자의 정보를 웹 서버와 주고 받아야하는 경우라면 HTTP는 정보 유출의 위험성을 갖게 된다. HTTPS는 침입자가 웹사이트와 사용자 사이의 통신을 몰래 수신하는 것을 방지함으로써 보안을 강화해준다.
  • getUserMedia()를 통한 사진 촬영이나 오디오 녹음, 프로그레시브 웹 앱과 같은 강력한 웹 플랫폼 신기능들은 실행하려면 사용자의 명시적인 권한 허락을 필요로 한다. 오래된 API들도 실행할 때 권한이 필요하도록 업데이트되고 있는데, HTTPS는 이러한 새 기능과 업데이트된 API에 대한 권한 허락을 가능하게 한다.
  • 네이버, 다음은 물론이고 구글 역시 검색 엔진 최적화(SEO: Search Engine Optimization) 관련 내용을 HTTPS 웹사이트에 대해서 적용하고 있다. 즉, 키워드 검색 시 상위 노출되는 기준 중 하나가 보안 요소이다.
  • 모든 사이트에서 텍스트를 암호화해서 주고 받으면 과부하가 걸려 속도가 느려질 수 있다. 중요한 사이트는 HTTPS로 관리하고, 그렇지 않은 사이트는 HTTP를 사용한다.
  • HTTPS를 지원한다고 해서 무조건 안전한 것은 아니다. 신뢰할 수 있는 CA 기업이 아니라 자체적으로 인증서를 발급할 수도 있고, 신뢰할 수 없는 CA 기업을 통해서 인증서를 발급받을 수도 있기 때문이다.

Rest API란?

  • REST 기반으로 서비스 API를 구현한 것
  • 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공

API(Application Programming Interface)란 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것

REST API 설계 기본 규칙

  • URI는 자원의 정보를 표시해야 한다.

    • resource는 동사보다는 명사를, 대문자보다는 소문자를 사용

    • resource의 도큐먼트 이름으로는 단수 명사를 사용

    • resource의 컬렉션 이름으로는 복수 명사를 사용

    • resource의 스토어 이름으로는 복수 명사를 사용

      GET /Member/1  -> GET /members/1

  • 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE) 로 표현

    • URI에 HTTML Method가 들어가면 안된다

      GET /members/delete/1 -> DELETE /members/1

    • URI에 행위에 대한 동사 표현이 들어가면 안된다(CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.)

      GET /members/show/1 -> GET /members/1
GET /members/insert/2 -> POST /members/2

    • 경로 부분 중 변하는 부분은 유일한 값으로 대체(즉 :id는 하나의 특정 resource를 나타내는 고유값)

      • Ex) student를 생성하는 route: POST/students
      • Ex) id=12인 student를 삭제하는 route: DELETE/students/12

REST API 설계 규칙

  1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.

    http://restapi.example.com/houses/apartments

  2. URI 마지막 문자로 슬래시를 포함하지 않는다

    • URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르며 URI도 달라져야 한다.

      http://restapi.example.com/houses/apartments/ (x)

  3. 하이픈(-) 은 URI 가독성을 높이는데 사용

    • 불가피하게 긴 URI 경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.

  4. 밑줄(_)은 사용하지 않는다.

    • 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용 x

  5. URI 경로에는 소문자가 적합

    • URI 경로에 대문자 사용은 피하도록 한다
    • RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문

  6. 파일 확장자는 URI에 포함하지 않는다.

+ RESTful의 개념

RESTful이란
  • RESTful은 일반적으로 REST라는 아키텍쳐를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
    • REST API를 제공하는 웹 서비스를 RESTful하다고 할 수 있다.
  • RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.
    • 즉, REST 원리를 잘 따르는 시스템은 RESTful 용어로 지칭된다.
RESTful의 목적
  • 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
RESTful하지 못한 경우
  • CRUD 기능을 모두 POST 로만 처리하는 API
  • route에 resource, id 외의 정보가 들어가는 경우