10.04 (HTTP)
HTTP란 HyperText Transfer Protocol의 줄임말로,
HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜이다.
이는 웹 브라우저와 웹 서버의 소통을 위해 디자인되었고,
클라이언트가 HTTP messages 양식에 맞춰 요청을 보내면 서버도 그 양식에 맞춰 응답한다.
+ 무상태성을 가진다. (무상태성 = 상태를 가지지 않는다. 클라이언트나 서버의 상태를 확인하지 않음)
HTTP Messages
쉽게 확인할 수 있는 HTTP messages의 요청과 응답 모델이다.
첫 줄에 요청이나 응답의 상태를 나타내는 start line(status line)이 존재하고,
요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합인 HTTP headers(메시지 정보라고 적혀있는 부분)
헤더와 본문을 구분하는 empty line(공백)
요청이나 응답에 관련된 데이터 또는 문서를 포함한 body(본문)가 유사하게 존재한다.
( + body는 유형에 따라 선택적으로 사용한다.)
요청(Request)
Start line
수행할 작업(Get, Put 등)이나 방식(Head or Options)을 설명하는 HTTP method를 나타낸다.
요청 대상(URL, URI 등)이나 프로토콜, 포트, 도메인의 경로는 요청 컨텍스트에 작성
(origin 형식, absoluter 형식, authority 형식, asterisk 형식이 존재하고 HTTP method마다 다르게 사용한다.)
HTTP 버전을 함께 입력한다.
- POST / HTTP/1.1
Headers
General headers = 메시지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와는 관련 x
Request headers = 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함
Representation headers(Entity headers) = body에 담긴 리소스의 정보를 포함
Body
요청의 본문.
Get, Head, Delete, Options처럼 서버에 리소스를 요청하는 경우 본문이 필요 x
응답(Response)
status line
현재 프로토콜의 버전
요청의 결과 (200, 201, 404 등)
상태 코드에 대한 설명이 나타난다.
- HTTP/1.1 404 Not Found
Headers(요청과 비슷)
General headers = 메시지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와는 관련 x
Request headers = 응답에 대한 부가적인 정보(위치, 서버 정보 등)를 갖는 헤더
Representation headers(Entity headers) = body에 담긴 리소스의 정보를 포함
Body
응답의 본문.
200, 404와 같은 상태 코드를 가지는 응답에는 본문이 필요 x
REST API
REST는 Representational State Transfer의 약자이다.
웹에서 사용되는 데이터나 자원을 HTTP API로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식이다.>
햄버거 집에 가서 "여기 맛난 햄버거 하나 주쇼" 하면 종업원은 어떻게 대처할까?
키오스크가 존재한다면 대부분은 "문 앞에 있는 키오스크를 이용해주세요^^" 할 것이다.
우리는 새로운 햄버거 집에 가서 어떠한 햄버거가 존재하는지 몰라도 키오스크를 통해
햄버거의 종류를 고를 수 있고, 자기가 추가하고 싶은 토핑을 추가할 수 있다
이를 통해 손님이 원하는 바를 종업원 또한 쉽게 확인한다.
이것이 REST API의 예시라고 할 수 있다.
서버는 적절한 API를 제공하고, 클라이언트는 제공된 API 양식에 맞춰서 서버에게 리소스를 요청할 수 있는 것이다.
REST API에는 4단계 모델이 존재한다.
0단계 = 단순히 HTTP 프로토콜 사용
1단계 = 개별 리소스에 맞는 엔드포인트 사용
2단계 = 적절한 HTTP 메서드를 사용
3단계 = 하이퍼미디어 컨트롤을 적용
→ 2단계까지만 적용해도 좋은 API디자인이라고 볼 수 있다.
2단계까지의 API구성을 정리
HTTP를 사용할 때
개별 리소스에 맞는 엔드포인트를 사용한다. (명사, 카멜케이스, 소문자 사용)
→ /appointment 와 같은 개괄적인 엔드포인트보다는 /king/sejong 과 같은 특정적인 엔드포인트를 사용해야 한다.
요청하고 받은 자원에 대한 정보를 응답으로 전달한다.
예를 들어 새로운 정보가 추가되었다면, 추가가 완료되었는지 안되었는지 그에 대한 정보를 전달해야 한다.
적절한 HTTP method를 사용한다.
GET = 요청 URI의 정보를 조회 (body가 없기 때문에 query parameter를 사용하여 필요한 리소스를 전달한다)
POST = 요청 URI의 리소스의 새로운 정보를 보냄 (요청마다 새로운 리소스가 생성, 응답 코드 201 Created로 명확하게)
PUT = 요청 URI에 저장될 정보를 보낸다. (전체 갱신) ( + PATCH = 일부분 갱신, 수정)
DELETE = 요청 URI의 리소스를 삭제
+
OPTIONS = 요청 URI에서 사용할 수 있는 method를 조회
HEAD = GET 요청에서 body는 제거하고 헤더만 가져옴
응답 코드
2xx = 성공
3xx = 리다이렉션(요청 완료를 위해 추가 작업 조치가 필요)
4xx = 클라이언트 요청 오류
5xx = 서버 내부 오류
오늘의 일기
오늘은 과제가 그렇게 어렵지 않았다.
그래서 페어 분과 이런저런 얘기도 하고 여유롭게 보낼 수 있었던 것 같다.
딥토크(그룹 회고)가 준비되어 있었기 때문에 미리 질문에 대한 고민을 했다.
모더레이터(진행자)에 랜덤으로 지정당해서 내향성 90퍼인 나는 발발 떨었지만
그래도 그룹 구성원 분들이 다 좋으신 분들이라 침착하게 차근차근 진행할 수 있었다.
가장 기억에 남는 것은 전공자분이 코드 스테이츠의 커리큘럼은 웹 개발에 있어 정말 좋은 구성으로 되어 있고
충분히 취직에 도움이 될 것이라고 해주신 게 기억에 남는다.
막연한 길은 아닐까 생각하던 것이 그래도 나보다는 조금이라도 더 아시는 분이 말씀해주시니 긍정적인 기운을 받았다.
비도 오고 그래서 조금은 기운이 가라앉아 있었는데 그런 긍정적인 기운을 받으니 에너지가 샘솟는 기분이었다.
그 에너지로 이번 주도 잘 마무리해보도록 하겠다!