const defaultCorsHeaders = {
"access-control-allow-origin": "*", // * -> 와일드 카드
"access-control-allow-methods": "GET, POST, DELETE, OPTIONS",
"access-control-allow-headers": "content-type, accept",
"access-control-max-age": 10, // Seconds.
};
ex) 닭갈비집 알바생이라 생각하자
닭갈비집 알바생(서버) : 요구를 하면 가져다줌
=> 요청을 받으면 요청한 내용을 보내주는 프로그램
ex) HTTP 요청 ...
요청은 크게 4개의 방식이 있음
ex) 닭갈비집 알바생 메이커
모뎀과 컴퓨터 사이에 데이터를 주고받을 수 있는 통로.
ex) 자동차가 지나다닐 수 있는 도로의 역할
-> 웹서버와 고객간의 소통방법 "어떻게 해야 서버랑 통신할 수 있을까"
(tmi)
다른 곳에서 URL 대신 URI 이런 용어를 많이 쓰기도 하는데
URI는 자료를 넘버링하고 분류하고 지칭하는 방법이라 보시면 됩니다. URL과 비슷하지만 조금 더 큰 의미입니다. 도서관에서 책 분류할 때 URI에 의해서 분류하기도 합니다.
Client-server 역할 구분하기
고객들은 그냥 URL 하나만 알면 서버에 있는 자료를 갖다쓸 수 있습니다.
고객에게 서버역할을 맡기거나 고객에게 DB에 있는 자료를 직접 꺼내라고 하든지 그런 식으로 코드를 짜시면 안됩니다.
Stateless
요청들은 각각 독립적으로 처리되어야합니다.
요청1이 성공해야 요청2를 보내주고 그런 식으로 요청간의 의존성이 존재하는 코드를 짜시면 안됩니다. 다르게 말하면 요청하나 만으로 자료를 가져오기 충분하도록 요청에 필요한 모든 정보들을 실어 보내는게 좋다는 뜻
Cacheable
요청을 통해 보내는 자료들은 캐싱이 가능해야합니다.
그리고 캐싱가능하다고 표시하거나 캐싱 기간을 설정해주어야 한다고 합니다.
(tmi)
캐싱?
네이버를 방문하면 크롬 브라우저는 자동으로 자주 사용하는 이미지 파일, CSS 파일 등을 하드에 저장해놓습니다.별로 바뀔일 없는 네이버 로고나 아이콘 같은거요.
하드에 저장해놓고 네이버 방문할 때 네이버서버에 네이버 로고주세요~라고 요청하지 않고 하드에서 불러옵니다. 이 행위를 캐싱이라고 합니다.
Layered System
요청처리하는곳, DB에 저장하는곳 이런 여러가지 단계를 거쳐서 요청을 처리해도 됩니다.멋있게 말하면 여러개의 레이어를 거쳐서 요청을 처리하게 만들어도 된다고 합니다.
Code on Demand
서버는 고객에게 실제 실행가능한 코드를 전송해줄 수도 있습니다.