[TIL] HTTP

Client-Server Architecture

• client는 server로부터 리소스를 받아와 앱에서 조회 가능하도록 구현
• 2-tier architecture를 사용하지 않으면 리소스가 업데이트 될 때마다 앱 자체를 업데이트 해야 함
• 3-tier architecture는 리소스를 데이터베이스에 저장하고, 서버는 클라이언트에게 리소스를 전달해주는 역할
• client와 server간의 통신은 특정 규약을 따라 이루어져야 함

HTTP

• 웹 서버 통신을 위한 통신 규약(protocol) 중 한 가지 (tcp/udp를 웹에 맞게 재설계)
• http만의 특성
  - 비연결성: 연결 상태를 유지하지 않고 송수신시마다 연결 요청
  • 무상태성: 이전의 상태를 저장하지 않음
• tcp의 경우 클라이언트-서버가 모두 켜져 있고 동일 포트로 연결이 되어 있어야 하지만, http는 그럴 필요성이 없다 (tcp가 전화 통화라면 http는 문자)

HTTP request

• client -> server
• 구성
  1. 시작줄 (request method, 사이트 주소, HTTP version)
  2. header (요청에 대한 정보)
  3. body (요청과 함께 보낼 데이터, 생략 가능)
• request methods
  - GET: 자료 요청 (READ)
  - POST: 자료 생성 (CREATE)
  - PUT: 자료 수정 (UPDATE)
  - DELETE: 자료 삭제 (DELETE)
  • OPTIONS: 요청한 URI에 대한 정보 요청가능 정보 (어떤 메소드가 가능한지? 등):

HTTP response

• server -> client
• 구성
  1. 시작줄 (상태 코드, 상태 메시지)
  2. header (응답에 대한 정보)
  3. body (요청한 데이터 // if applicable)
• 상태 코드
  - 1xx 정보: 요청을 받아 진행 중
  - 2xx 요청 성공 (200 OK, 201 Created 등)
  - 3xx 리다이렉션: 요청 완료를 위해 추가 작업 필요
  - 4xx 클라이언트 에러 (400 Bad Request, 404 Not Found 등)
  - 5xx 서버 에러

Application Programming Interface (API)

• 리소스 전달을 위한 메뉴판과 같은 존재

RESTful API

• Representational State Transfer (REST)
• HTTP의 장점을 극대화할 수 있는 network achitecture
• 모든 웹 리소스에 대해서 고유한 URI를 부여
• 6 Principles of REST
  1. Uniform Interface: 모든 리소스 요청에 대해서 일관된 interface 사용
  2. Client-Server: 서버와 무관하게 클라이언트 작성
  3. Stateless: 하나의 요청에 모든 정보를 넣어줘야 한다 (서버가 맥락을 기억하기를 예상하면 안 됨)
  4. Cacheable: 특정 정보는 미리 서버에 저장되어야 한다
  5. Layered system: system architecture에 여러 서버가 있을 수 있고 클라이언트는 어느 서버에서 가져오는지 알 수 없다
  6. Code on demand (optional): 서버에서 클라이언트 측에서 실행할 코드를 보낼 수 있다
• REST Best Practices
  - nouns to represent resources
  • consistency
  • URI without CRUD method names
  • query component to filter
• un-RESTful API의 예: CRUD 기능을 모두 POST 요청으로만 처리

Ajax

• Asynchronous JavaScript and XML
• XMLHttpRequest를 이용하여 서버와 자유롭게 통신 -> 현재는 fetch API도 이용 가능
• 페이지의 일부 (필요한 부분)만 업데이트 해 페이지 깜빡임 없이 작동

Browser Security

CORS

• Cross-Origin Resource Sharing
• 다른 origin을 가진 서버에 리소스 요청을 해도 허용하도록 설정하는 HTTP header
• 예: domain-a.com에서 domain-b.com에 리소스 요청을 한다면 CORS 허용이 되어야만 접근 가능하다

XSS attack

• 보안이 약한 web application에 대한 웹 기반 공격
• 앱에 POST요청으로 악성 코드를 삽입하고, 클라이언트가 GET요청을 하면 악성 코드를 받아 해커의 서버로 정보를 넘길 수 있다
• 정규 표현식 등을 사용하여 POST요청으로 넘어오는 악성 코드의 경우 걸러 주는 방식으로 방어 가능