2019-12-16 TIL
December 16, 2019
주간목표
- Rest api를 사용하여 웹서버를 구현하겠습니다.
- Data Base를 만들겠습니다.
일일 목표
- Rest api 구조와 특징에 대해 다시 공부하겠습니다.
- 이전 api예제를 따라 쳐보면서 res api 이해해보겠습니다.
- express의 특징, 구조, 사용법 다시 공부하겠습니다.
결과
- Rest Api 구조 및 특징 공부
- front에서 서버에 저장된 productStore를 요청하여 가져온다.
Rest Api
- Representational State Transfer (표현 상태 전달?)
- Rest는 HTTP기반으로 필요한 자원(DB, 서비스 등)에 접근하는 방식을 정해놓은 아키텍쳐
- 구성요소 : Resource, Method, Message 세가지로 구성되어있습니다.
Rest Api 4개의 속성(특징)
- URI로 자원에 접근한다. 서버에 있는 모든 resource에는 클라이언트가 접근할 수 있는 고유 URI를 갖고있다.
- 모든 요청은 클라이언트가 요청할 때 마다 필요한 정보를 주기 때문에 서버에서는 세션 정보를 보관할 필요가 없다 -> 유연한 아키텍처
- HTTP 메소드를 사용한다. 모든 resource는 http인터페이스인
GET, POST, PUT, DELETE4개의 메소드로 접근되어야 한다. -
서비스 내의 하나의 resource가 주변에 연관된 resource들과 연결되어 표현이 가능하다.
예를들어 나는 카카오에서 제공하는 API를 사용하고싶다. API를 사용하기 위한 방법중 하나로 REST를 사용할 수 있다. 이것을 REST API라고 부른다. REST 방식으로정보를 요청하고 받아오는것이다.
HTTP 메소드
- GET : 가져오다
- POST : 게시하다
- PUT : 집어넣다(전체수정/ 대체)
- PATCH : 고치다(부분수정)
- DELETE : 지우다
CORS
- 다른 출처(도메인, 프로토콜, 포트)를 가진 리소스를 요청할 때 실행됩니다.
- 추가 HTTP 헤더를 사용합니다.
- 브라우저가 접근 권한을 부여하도록 합니다.
-
브라우저는 실제 요청을 전송하기 전에 OPTIONS 메소드를 이용해서 preflight 요청을 서버로 전송합니다. preflight 요청을 받은 서버는 CORS 관련 정보를 헤더에 담아서 클라이언틀 전송합니다.
현재 페이지의 출처(도메인, 프로토콜, 포트)와 하나라도 다른 출처를 가진 페이지에 접근하려 할 때 보안상의 이유(Same Origin Policy)로 인해 요청(접근)이 불가능 합니다.
하지만 REST API등의 외부 호출이 많아지고, 여러 도메인에 대규모로 구성되는 웹 프로젝트가 많아지면서 불편한 정책이 되었습니다. 그래서 웹 브라우저에서 외부 도메인 서버와 통신하기 위한 방식을 표준화 하기위해 CORS가 나왔습니다.
클라이언트는 CORS요청을 하기 위해 새로운 HTTP헤더를 추가합니다. 서버는 클라이언트가 전송한 헤더를 확인해서 요청을 하용할지 말지를 결정합니다. 데이터 사이드 이펙트를 일으킬 수 있는 HTTP 메소드를 사용할 때는 먼저 preflight 요청을 서버로 전송해서 서버가 허용하는 메소드 목록을 HTTP OPTIONS헤더로 획득한 다음에 실제 요청을 전송합니다.
- Preflight Request 추가 공부하기
5FS
Facts
- 오전 알고리즘 테스트 30분
- Rest Api의 구조와 개념에 대해 오랜만에 공부했습니다.
Feelings
- 새로운 정보를 습득하는게 여전히 어려운가?
Findings
- 알고리즘 공부 겨우 2일 안했다고 내장객체 사용법이 생각나지 않았다.
- 서버와 관련해선 3주전에 공부한것이 전부라 다시 처음부터 보는 느낌이었다. 신기한건 그때 보다 문서가 더 잘 이해되는것 같았고 내 코드에 적용하기가 좀 더 수월해진것 같았다. 3주전에 비해 더 성장한것이라고 믿고싶다.
Future Action Plan
- 매일 아침 알고리즘 테스트
- MDN 영어문서 읽기 (어려워보여도 무조건 공식사이트로 공부하기)
