Chatterbox Client 스프린트는 프리코스 때 했던 Twittler 스프린트와 비슷했지만, Twittler 스프린트는 DOM을 위주로 했기 때문에 Client쪽에서만 상호작용이 일어났다면, 이번 Chatterbox 스프린트는 Client쪽에서 Server로 데이터를 요청하고 응답을 받아 이를 보여주도록 해야한다는 점(Client와 Server 간 상호작용)에서 차이가 있었다. 즉 이번 스프린트의 핵심은 'API를 활용해서 UI를 만드는 것'이었다.
API(Application Programming Interface): 프로그래밍 되어있는 어플리케이션과 의사소통 가능한 매개체
UI(User Interface): 사용자와 의사소통 가능한 매개체
Interface: 사물 간 또는 사물과 사람 간의 의사소통이 가능하도록 만들어진 매개체
웹 구조(Web Architectures)는 크게 Client, Server, DB로 구성되어 있다. Client는 브라우저 상에서 돌아가는 어플리케이션으로 사용자와 상호작용을 담당하며, Server 어플리케이션은 Client로부터 요청을 받으면 데이터베이스에 있는 데이터를 가져와서 응답을 주는 요청과 응답 처리를 담당한다.
이미지출처: codestates urclass
Client에서 Http라는 프로토콜을 활용해서 Server API에 요청을 하면 Server는 그 요청과 응답을 처리하여 Client에 넘겨준다. 이후 Client는 브라우저 상에서 자바스크립트를 구동하여 보이는 부분을 변화시키는 과정이 이루어진다.
이미지출처: codestates urclass
웹 구조(Web Architectures)의 기본 요소
1. 브라우저(Browser)
브라우저는 2진수만 알아들을 수 있는 컴퓨터가 HTML, CSS, JS로 작성한 코드를 볼 수 있도록 해주는 역할을 한다. 즉 HTML, CSS, JS로 코드를 작성하면 브라우저 내부 엔진인 V8이 이 코드를 해독하여 컴퓨터에 데이터를 넘겨주게 되고, 컴퓨터가 데이터를 처리한 결과를 브라우저에 보여주게 된다. 인터넷 익스플로어가 왜 망했는지??
이미지 출처: codestates urclass
2. 서버(Server)
자원을 제공(serve)하는 주체. 서버는 스타벅스에 비유를 들 수 있다. 즉 Client가 커피 원두를 음료로 마시려면 DB에서 원두를 꺼내와서 음료를 제조하는 서버의 역할이 필요하다. 서버는 Client의 요청을 받으면 리소스(resource)를 바탕으로 응답한다.
이미지 출처: codestates urclass
3. API(Application Programming Interface)
서버는 Client에게 DB에 있는 리소소를 잘 활용할 수 있도록 Interface를 제공해줘야 한다. 즉 API는 서버 자원을 잘 가져다 쓸 수 있게 만들어 놓은 Interface이다. 스타벅스에 비유를 들자면 API는 스타벅스의 메뉴판이라고 할 수 있다. 메뉴판(API)이 있어야 서버는 원두를 바탕으로 음료(리소스)를 만들어 제공할 수 있다.
이미지 출처: codestates urclass
4. HTTP(HyperText Transfer Protocol)
Client와 Server가 통신을 할 때 어떤 규약(Protocol)을 지켜서 하는데 이를 HTTP라고 한다.
1) 항상 요청(Request)과 응답(Response)로 이루어진다(Client-Server).
2) Client가 메세지를 달라고 하면 Server는 메세지를 준다(없으면 없다고 응답하며, 요청을 무시할 경우 오류 발생).
3) HTTP 요청은 Header와 Body로 이루어진다. Header에는 어디서 보내는 요청인지(origin), 콘텐츠 타입은 무엇인지(content-type), 어떤 Client를 이용해 보냈는지(user-agent)에 대한 정보가 들어가고, Body는 메소드에 따라 있을 수도 없을 수도 있는데 Server에 데이터를 보내기 위한 공간으로 활용된다.
4) 응답 또한 요청와 같은 구조를 갖는다.
5) HTTP의 각 요청은 모두 독립적이다(Stateless). 다시 말해, Client와 Server 간 요청과 응답이 한 번 오갔다면, 다음 요청은 이전 요청과 별개의 것이기 때문에 이전 요청의 문맥(Context)이 이어지지 않는다. 따라서 이를 보완하기 위해 인증이라는 수단을 거쳐야 한다.
6) 한 번의 요청에는 한 번의 응답을 한다(Connectionless). 즉 응답 이후에는 연결이 끊기기 때문에 더 이상 응답을 할 수 없고 다시 요청을 해야 한다.
7) HTTP는 대표적으로 GET, POST, PUT, DELETE메소드를 가지고 있다. GET은 서버에 자원을 요청할 때, POST는 서버에 자원을 생성할 때(데이터를 서버로 제출하는 용도), PUT은 서버의 자원을 수정할 때(ex.프로필 업데이트), DELETE는 서버의 자원을 제거할 때 쓰인다.
5. Ajax(Asynchronous Javascript and XML)
예전에는 form태그를 이용하여 페이지 전환과 요청에 대한 응답을 받아올 때, 필요한 부분만이 아닌 페이지 전체가 로딩되는 번거로움이 있었다. 이를 보완하기 위해 서버와 자유롭게 통신할 수 있는 XMLHttpRequest(XHR)가 등장하였고, 페이지 깜빡임 없이 seamless하게 작동하는 JavaScript와 DOM을 이용하게 되었는데, 이 둘을 합한 개념이 Ajax(Asynchronous Javascript and XML)이다.
서버와 통신하기 위해 XMLHttpRequest, jQuery방식을 사용하다가 보다 쓰기 쉬운 표준 API로 Fetch API가 많이 활용되고 있다. 그러나 fetch가 전부 좋은 것은 아니며, XMLHttpRequest도 여전히 많이 쓰인다.fetch('http://52.78.213.9:3000/messages') //GET요청 .then(function(response) { return response.json(); //JSON형태의 데이터를 JS Object형태로 변경 }) .then(function(json) { // json 형태로 전달받은 서버로부터의 응답 // JS, DOM을 조작하여 필요한 페이지만 수정 });
브라우저 보안(Browser Security)
1. XSS, CSRF공격
브라우저가 위협을 받는 근본적인 이유는 바로 브라우저가 자바스크립트를 구동하기 때문이다. 브라우저 보안에 위협이 되는 대표적인 공격으로 XSS와 CSRF가 있다.
XSS: Client가 Server로부터 받는 데이터를 정상적이라고 신뢰하기 때문에 발생하는 문제. 브라우저들이 업데이트 되면서 기본적인 XSS공격은 막혀있다.
CSRF: Server가 Client를 신뢰해서 발생하는 문제. 서버는 브라우저의 인증정보를 가지고 오면 해당 사용자라고 믿기 때문에, 사용자가 인증정보를 가진 채로 해커의 링크를 누르면, 해커는 인증정보를 가로채서 서버에 요청을 보내 버린다.
2. CORS(교차 출처 리소스 공유, Cross-Origin Resource Sharing)
MDN정의에 따르면 CORS는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다.
보안 상의 이유로, 브라우저는 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다. 이는 브라우저가 자발적으로 브라우저의 어플리케이션을 사용하는 사용자들을 보호하기 위한 보안 조치로 이해할 수 있다.
2.1 접근 제어 시나리오 예제
1. 단순 요청(Simple Request): GET/HEAD/POST메소드 중 하나 사용.
2. 미리전송 요청(Preflight Request): "preflighted" request는 단순 요청과는 달리, 먼저 OPTIONS 메서드를 통해 다른 도메인의 리소스로 HTTP 요청을 보내 실제 요청이 전송하기에 안전한지 확인한다. Cross-site 요청은 유저 데이터에 영향을 줄 수 있기 때문에 미리 전송(preflighted)한다.
3. 인증정보를 포함한 요청(Credentialed requests): HTTP cookies 와 HTTP Authentication 정보를 인식한다.
**내용 출처: MDN내용 정리
