Http & REST API

InSeok·2022년 8월 8일
TIL부트캠프
0

TIL

목록 보기
22/51

목차

  1. HTTP 메시지
  2. HTTP 메서드
  3. MIME타입
  4. CORS

배운 내용

HTTP

HTTP(HyperText Transfer Protocol)

  • HTML과 같은 문서를 전송하기 위한 Application Layer프로토콜
  • 웹 브라우저상에서 클라이언트와 서버간의 통신을 담당
  • 클라이언트가 HTTP messages 양식에 맞춰 데이터 요청을 보내면, 서버도 HTTP messages 양식에 맞춰 응답
  • 특정 상태를 유지하지 않는 무상태성(Stateless)

**HTTP messages**

  • 클라이언트와 서버 사이에서 데이터가 교환되는 방식

Untitled

  1. start line : start line에는 요청이나 응답의 상태를 나타냅니다. 항상 첫 번째 줄에 위치합니다. 응답에서는 status line이라고 부른다.
  2. HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합입니다.
  3. empty line : 헤더와 본문을 구분하는 빈 줄이 있습니다.
  4. body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함합니다. 요청과 응답의 유형에 따라 선택적으로 사용합니다.
  • 헤드(head) : 1 +2
  • payload : body

**요청(Requests)**

  • 클라이언트가 서버에 보내는 메시지

**Start line**

  1. 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타냄
  2. 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성

method 마다 다릅니다.

  • origin 형식 : ?와 쿼리 문자열이 붙는 절대 경로입니다. POST, GET, HEAD, OPTIONS 등의 method와 함께 사용합니다.
    POST / HTTP 1.1GET /background.png HTTP/1.0HEAD /test.html?query=alibaba HTTP/1.1OPTIONS /anypage.html HTTP/1.0
  • absolute 형식 : 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용합니다.
    GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
  • authority 형식 : 도메인 이름과 포트 번호로 이루어진 URL의 authority component 입니다. HTTP 터널을 구축하는 경우, CONNECT와 함께 사용할 수 있습니다.
    CONNECT developer.mozilla.org:80 HTTP/1.1
  • asterisk 형식 : OPTIONS 와 함께 별표() 하나로 서버 전체를 표현합니다.
    OPTIONS * HTTP/1.1
  1. HTTP 버전에 따라 HTTP message의 구조가 달라집니다. 따라서 start line에 HTTP 버전을 함께 입력

**Headers**

Untitled

  • 헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값을 입력
  1. General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더
  2. Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
  3. Representation headers : body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더

**Body**

  • GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다.
  • POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용
  • Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성
  • Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닌다. 보통 HTML form과 관련

**응답(Responses)**

**Status line**

  • 응답의 첫줄 , ex) HTTP/1.1 404 Not Found.
  1. 현재 프로토콜의 버전(HTTP/1.1)
  2. 상태 코드 - 요청의 결과를 나타냅니다. (200, 302, 404 등)
  3. 상태 텍스트 - 상태 코드에 대한 설명

**Headers**

Untitled

  • 요청 헤더와 동일한 구조
  • General headers
  • Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더, 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공
  • body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더

**Body**

  • 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 불필요
  • Single-resource bodies(단일-리소스 본문) :
    • 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의
    • 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked
      로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어있다.
  • Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body

**Stateless(무상태성)**

  • HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않는다.

HTTP 요청 메서드

  • 클라이언트가 웹 서버에게 사용자 요청의 목적이나 종류를 알리는 수단

주요 메소드 5가지

  • GET : 리소스 조회
  • POST : 요청 데이터 처리, 주로 데이터 등록에 사용
  • PUT : 리소스를 대체, 해당 리소스가 없으면 생성
  • PATCH : 리소스를 일부만 변경
  • DELETE : 리소스 삭제

기타 메서드 4가지

  • HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
  • OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명(주로 CORS에서 사용)
  • CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
  • TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

GET

  • 보통 리소스를 조회할 때 사용하며, 서버에 전달하고 싶은 데이터는 query를 통해서 전달

POST

  • 데이터 요청을 처리하고, 메시지 바디를 통해 서버로 데이터를 전달한다. 주로 신규 리소스를 등록하거나 프로세스 처리에 사용

PUT

  • 리소스가 있으면 대체하고 리소스가 없으면 생성

PATCH

  • PUT과 마찬가지로 리소스를 수정할 때 사용하지만, PATCH는 리소스를 일부분만 변경할 수 있다.

DELETE

  • 리소스를 제거

**HTTP 메소드의 속성**

  • 안전(Safe Methods)
    • 계속해서 메소드를 호출해도 리소스를 변경하지 않는다 -GET메소드가 안전
  • 멱등(Idempotent Methods)
    • 메소드를 계속 호출해도 결과가 똑같다
    • Get, PUT, DELETE는 멱등 O
    • POST나 PATCH는 멱등 X
  • 캐시가능(Cacheable Methods)
    • 캐싱을 해서 데이터를 효율적으로 가져올 수 있다는 뜻
    • GET, HEAD, POST, PATCH가 캐시가 가능하지만 실제로는 GET과 HEAD만 주로 캐싱이 쓰인다

**HTTP 상태코드**

  • 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
  • 1xx (Informational): 요청이 수신되어 처리중 → 거의 사용안함

2xx (Successful): 요청 정상 처리

  • 200 OK : 요청 성공
  • 201 Created : 요청 성공해서 새로운 리소스가 생성됨
  • 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음
  • 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

3xx (Redirection): 요청을 완료하려면 추가 행동이 필요

  • location 헤더가 있으면 location 위치로 자동 이동하는 것을 리다이렉트라고 한다.
  • 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
  • 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
  • 303 See Other : 리다이렉트시 요청 메서드가 GET으로 변경
  • 304 Not Modified : 캐시를 목적으로 사용
  • 307 Temporary Redirect : 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다.)
  • 308 Permanent Redirect : 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음

  • 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
  • 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 필요함
  • 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함
  • 404 Not Found : 요청 리소스를 찾을 수 없음

5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

  • 500 Internal Server Error : 서버 문제로 오류 발생, 애매하면 500 오류
  • 503 Service Unavailable : 서비스 이용 불가

프로토콜 : 통신 규약(약속)

API

  • 서버에는 마치 식당에서 메뉴판을 제공하듯, 리소스를 잘 활용할 수 있도록 클라이언트에게 API를 제공해야한다.
  • 보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근

**REST API**

  • Representational State Transfer (REST)
  • 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식

좋은 REST API 디자인을 위한 4단계 모델

Untitled

  • 2단계까지만 적용해도 좋은 API 디자인

0단계

  • 단순히 HTTP 프로토콜을 사용하기만 해도 된다.

Untitled

**1단계**

  • 모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야 한다
  • 어떤 리소스를 변화시키는지 혹은 어떤 응답이 제공되는지에 따라 각기 다른 엔드포인트를 사용
  • 요청하고 받은 자원에 대한 정보를 응답으로 전달해야 한다
  • 엔드포인트 작성 시에는 동사, HTTP 메서드, 혹은 어떤 행위에 대한 단어 사용은 지양하고, 리소스에 집중해 명사 형태의 단어로 작성
  • 요청에 따른 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공/실패 여부를 반환

Untitled

2단계

  • CRUD에 맞게 적절한 HTTP 메서드를 사용하는 것에 중점
  • 응답 코드도명확하게 작성해야 하며, 관련 리소스를 클라이언트가 Location 헤더에 작성된 URI를 통해 확인할 수 있도록 해야한다.
  • GET 메서드 같은 경우는 서버의 데이터를 변화시키지 않는 요청에 사용
  • POST는 요청마다 새로운 리소스를 생성하고 PUT은 요청마다 같은 리소스를 반환
  • 멱등성(idempotent) : 매 요청마다 같은 리소스를 반환하는 특징 - Put 메서드
  • PUT은 교체, PATCH는 수정의 용도로 사용

Untitled

**3단계**

  • 응답에 리소스의 URI를 포함한 링크 요소를 삽입하여 작성
  • 응답에 들어가게 되는 링크 요소는 응답을 받은 다음에 할 수 있는 다양한 액션들을 위해 많은 하이퍼미디어 컨트롤을 포함

**Open API**

  • 공공데이터에 쉽게 접근할 수 있도록 정부는 Open API의 형태로 공공데이터를 제공
  • 누구에게나 열려있는 API
  • 기관이나 API마다 정해진 이용 수칙이 있고, 그 이용 수칙에 따라 제한사항(가격, 정보의 제한 등)이 있을 수 있습니다.

**API Key**

  • API를 이용하기 위해서는 API Key가 필요

  • API key는 서버의 문을 여는 열쇠

  • 로그인된 이용자에게만 자원에 접근할 수 있는 권한을 API Key의 형태로 제공하고, 데이터를 요청할 때 API key를 같이 전달해야만 원하는 응답을 받을 수 있다.

    더 자세한 내용은 링크 참조 : https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

어려운 내용

  • 로그인은 보통 Post메서드를 사용, 왜 Get이 아니냐? → GET메서드는 서버에 변화를 주면안되는데, 로그인을 하면 서버내부에 세션을 새로생성하여 정보를 저장하기 때문에

캐시

캐시 / 캐싱이란?

MIME 타입

  • MIME( Multipurpose Internet Mail Extensions)
  • 데이터 유형을 식별하는데 사용되는 레이블
  • 인터넷 미디어 유형(Content-type)은 MIME 유형과 동일
  • MIME 유형은 인터넷에서 파일 유형을 분류하는 표준 방식을 형성
  • 소프트웨어가 데이터를 처리하는 방법 알 수 있게한다.
  • 유형과 하위 유형의 두 부분으로 구성

**MIME 유형의 작동 방식**

  • 서버는 HTTP 응답 헤더에 MIME 유형을 삽입한다.
  • 클라이언트는 응답이 나타내는 데이터 유형에 적합한 “플레이어” 애플리케이션을 선택한다.
  • 이러한 플레이어 중 일부는 웹 클라이언트 또는 브라우저에 내장되어 있다.

작동 예시

  • HTTP 응답에 정의된 헤더 Content-Type 값을 사용하여 브라우저는 적절한 확장자 / 플러그인으로 파일을 열 수 있다. 이러한 플레이어 중 일부는 브라우저에 내장되어 있다. (브라우저에는 GIF, JPEG 이미지 플레이어와 HTML 파일 처리 기능이 함께 제공된다.)
  • 브라우저는 파일 확장자가 아닌 MIME 유형을 사용하여 URL을 처리하는 방법을 결정한다. 그러므로 웹 서버가 응답 Content-Type 헤더에 올바른 MIME 유형을 전송하는 것이 중요하다. 이것이 올바르게 구성되지 않으면 브라우저가 파일의 내용을 잘못 해석하고 사이트가 제대로 작동하지 않으며, 다운로드한 파일이 잘못 처리 될 수 있다.

자세한 내용은 아래 링크 참조

https://velog.io/@ragnarok_code/MIME이란-무엇인가

https://server-talk.tistory.com/183

cors

[WEB] 📚 CORS 개념 💯 완벽 정리 & 해결 방법 👏

https://it-eldorado.tistory.com/163

참조:https://kyun2da.dev/CS/http-메소드와-상태코드/

https://hanamon.kr/네트워크-mime-유형이란/

profile
InSeok
백엔드 개발자
이전 포스트

[네트워크] 웹 애플리케이션

다음 포스트

Graph / Tree / BsT

0개의 댓글