(펌)HTTP 그리고 REST API 다가가기

jinbroing.tistory.com/96

[웹기본개념] HTTP 그리고 REST API 다가가기

 

설명이 너무 잘 되어있습니다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

 

 

[HTTP란]

- HyperText Transper Protocol의 준말, 하이퍼텍스트 트랜스퍼란 링크 기반으로 데이터를 요청하고 받겠다는 것

- 클라이언트와 서버가 요청을 하고 응답을 하기위해 따르는 프로토콜

- HTML 문서를 주고 받을 수 있음, 뿐만 아니라 이미지, 동영상, 오디오, 텍스트 문서 등을 주고 받을 수 있음

 

 

[HTTP 동작 방식]

 

- 클라이언트 : 웹어플리케이션의 경우 크롬, 파폭, IE 등 브라우저를 통햇허 서버에 요청을 함(프로토콜 + 도메인 + URI)

- 서버 : 클라이언트로부터 받은 요청을 내부적으로 처리하여 그에 대한 결과를 응답해줌

 

 

[HTTP 특징 및 기능]

1) connectless + stateless

- 1번 요청-응답 후 연결을 끊어버림

- 클라이언트의 이전 상태를 알 수 없음 : 그래서 쿠키와 세션(클라이언트와 서버의 이전 상태정보 저장)이 필요함

- 수십만명이 웹서비스를 사용(요청)하더라도 최소 유지를 할 수 있기 때문에, 많은 유저의 요청을 처리할 수 있음

 

2) keep-alive : HTTP 1.1부터 지원하는 기능

- 1번 항목에서 언급했듯이 HTTP는 1번의 요청에 대해 1번의 응답 하는 것을 기준으로 설계됨

- 요즘 웹사이트들을 보면 하나의 페이지에 수십개 이미지, css 파일, js 파일이 있는 것을 볼 수 있음

- 1 요청 1응답 기준이라면 여러번 연결을 끊었다 붙였다 해야함 굉장히 비효율적

- keep-alive 지원으로 지정된 시간동안 연결을 끊지않고 연결된 상태를 유지할 수 있음

- keep-alive time out 내 클라이언트가 재요청하면 새로운 연결이 아닌 연결된 것을 이용함

1) 웹서버 연결

2) HTML 문서 다운로드

3) 필요한 img, css, js 등 다운로드

4) 연결 끊음

 

- 모든 웹서버, 브라우저가 HTTP 1.1 지원

- 아래는 네이버 페이지에 대한 요청 헤더임 

 

[HTTP Request 구조]

- 사용자(클라이언트 프로그램을 이용한)가 서버에 요청을 보낼 때 HTTP Request 구조를 알아본 것

 

 

1) 메소드(Header) : 사용자가 서버에 요청하는 메소드, HTTP 버젼을 확인할 수 있음

2) 요청헤더(Header) : 서버에 전달되는 사용자 정보(클라이언트 브라우저 정보 : 문자코드, 언어, 파일 종류)

3) 공백 : HTTP Request Header(헤더)와 본문 부분을 구분하기위한 공백

4) 본문(message) : HTTP Request 요청 메세지를 담고 있는 부분, GET 메소드의 경우 요청정보가 주소에 담겨져 있어 본문은 빈 상태

 

- 아래는 해당 페이지 HTTP Request의 header 부분의 이미지 : 요청 본문 아님

 

 

[HTTP Response 구조]

- 서버가 사용자 요청에 대한 응답을 할 때 HTTP Response 구조를 알아본 것

 

 

1) 상태코드(Header) : 사용자의 요청에 대한 서버 처리결과를 나타냄(200, 404, 500 등 여러 상태코드가 있음)

2) 응답헤더(Header) : 사용자에게 전달한 데이터 정보를 나타냄

3) 공백 : HTTP Response Header(헤더)와 본문 부분을 구분하기위한 공백

4) 본문(message) : 사용자에게 전달한 데이터 내용을 담고 있음(요청에 대한 데이터 응답)

 

- 아래는 해당 페이지 HTTP Request의 header 부분의 이미지 : 응답 본문 아님

 

[HTTP method 그리고 REST API]

- 메소드란? 요청의 종류를 서버에 알리기위해 사용하는 것, 게시판 기능(CRUD, REST API)을 만들 때 사용

- 메소드 종류

1) GET : 정보를 요청하기위해 사용(Read)

2) POST : 정보를 입력하기위해 사용(Create)

3) PUT : 정보를 업데이트하기위해 사용(Update)

4) DELETE : 정보를 삭제하기위해 사용(Delete)

 

- REST API란? HTTP 프로토콜 장점을 살릴 수 있는 네트워크 기반 아키텍처

1) REST API를 구현하기위해 HTTP method + 모든 개체 리소스화 + URL 디자인(라우팅) 필요

- 라우팅이란? 클라이언트의 요청에 대한 결과(응답)를 어떻게 이어줄 것인가를 처리하는 것

- URI를 이용한 접근 : 모든 개체를 리소스로 보고, 리소스에 고유번호를 부여

- URL 디자인 원칙 : 자원에 대한 처리를 주소에 나타내지않는다(HTTP method는 내부적으로 처리하도록), 어떤 자원인지 주소에 명확하게 나타냄

 

- 레일즈로 REST URL 디자인한 것

- book 이라는 자원(db 테이블 구현)에 대한 처리를 설계함

- 실제 주소는 http://도메인/books 혹은 뒤에 book 자원 중 하나에 대한 처리(:id), book 자원 새로 만들기 new 만 있음

- update, delete, read(show)를 주소 상에서 보여주지 않음

 

- REST API를 구현하기위해 HTTP 프로토콜에 대한 이해, method 종류, 라우팅에 대한 이해가 있어야함

- HTTP method를 클라이언트가 요청할 때 서버에 넘길 수 있도록(처리 각각에 맞는)

 

 

[참고자료]

1) 위키피디아 HTTP : https://ko.wikipedia.org/wiki/HTTP

2) joinc.com HTTP : https://www.joinc.co.kr/w/Site/Network_Programing/AdvancedComm/HTTP

3) exoluse 블로그 : http://exoluse.egloos.com/v/4572381

4) Wooeong's lab : http://wooeong.tistory.com/entry/HTTP%EB%9E%80

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

 

Ajax 통신을 사용할때 Request Header를 개발자가 잘 생각해서 써야하는데 , 이 글을 읽는다면

Request Header 작성에 도움이 될 것 같습니다.