Tie up loose ends!

1. 캐시 기본 동작 (데이터 크기는 HTTP 헤더 0.1M, HTTP 바디 1.0M 로 총 1.1M 로 가정한다.) 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 매우 느리고 비싸다. 브라우저 로딩 속도가 느리다. 캐시 적용 요청이 오면 http 헤더의 cache-control 부분에 캐시 가능 시간(유효 시간)을 응답으로 보낸다. 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르다. 캐시 적용했지만 캐시 가능 시간이 지난 경우 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고 캐시를 갱신한다. 이때 다시 네트워크 다운로드가 발생한다...

[1] HTTP 표준의 변화 - 1999년, RFC2616 (현재 폐기됨) HTTP 헤더: HTTP 전송에 필요한 모든 부가정보 (예) 메세지 바디의 내용, 메세지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등 다수가 존재함 General 헤더: 메세지 전체에 적용되는 정보 Request 헤더: 요청 정보 Reponse 헤더: 응답 정보 Entity 헤더: 엔티티 본문의 데이터를 해석할 수 있는 정보 HTTP 바디 메세지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터 - 2014년, RFC7230~7235 등장 엔티티(Entity) → 표현(Representation) 표현 = 표현..

[1] 상태 코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (Informational): 요청이 수신되어 처리 중 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 [2] 2xx - 성공(Successful) 클라이언트의 요청을 성공적으로 처리 200 OK: 요청 성공 201 Created: 요청 성공해서 새로운 리소스가 생성됨 (응답 헤더 Location 부분에 리소스 위치를 반환함) 202 Accepted: 요청은 접수되었고..

[1] 클라이언트에서 서버로 데이터 전송 - 데이터 전달 방식은 크게 2가지로 나뉜다. 쿼리 파라미터를 통한 데이터 전송 GET 검색어나 정렬 필터에 주로 사용 메세지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 등 - 정적 데이터 조회 (쿼리 파라미터 미사용) 이미지, 정적 텍스트 문서 GET 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 - 동적 데이터 조회 (쿼리 파라미터 사용) 주로 검색, 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용 GET 으로 쿼리 파라미터 사용해서 데이터를 전달 - HTML Form 데이터 전송 HTML Form 전송은 GET, POST만 지원함 POST 전송시 Con..

[1] HTTP API 를 만들어보자! ex) 회원 정보 관리 API를 만들어라. 회원 목록 조회 /read-member-list 회원 조회 /read-member-by-id 회원 등록 /create-member 회원 수정 /update-member 회원 삭제 /delete-member - 이것은 좋은 URI 설계일까? 가장 중요한 것은 리소스 식별이다. 회원을 조회하라, 회원을 등록하라라는 자체가 아니라 '회원'이 리소스가 되어야 한다. 즉 조회하고 등록하는 '행위'와, 회원이라는 '리소스'를 분리하고, 회원 리소스를 URI에 매핑해야 한다. 회원 목록 조회 /members (계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장. member → members) 회원 조회 /members/{id} 회..

[1] HTTP (Hyper Text Transfer Protocol) HTML 과 같은 텍스트를 전달하는 용도로 시작했으나 지금은 HTTP 메세지에 모든 것을 전송한다. HTML, Text IMAGE, 음성, 영상, 파일 JSON, XML (API) 서버 간 데이터를 주고 받을 때도 대부분 HTTP 사용 역사 HTTP/0.9 (1991): GET 메서드만 지원, HTTP 헤더 없음 HTTP/1.0 (1996): 메서드, 헤더 추가 HTTP/1.1 (1997): 가장 많이 사용함, RFC2068(1997) → RFC2016(1999) → RFC7230~7235(2014) HTTP/2 (2015): 성능 개선 HTTP/3 (진행중): TCP 대신 UDP 사용, 성능 개선 기반 프로토콜 TCP: HTTP/1..

[1] URI (Uniform Resource Identifier) Uniform: 리소스를 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것 Identifier: 다른 항목과 구분하는데 필요한 정보 [2] URL (Uniform Resource Locator) / URN (Uniform Resource Name) URL - Locator: 리소스가 있는 위치를 지정 URN - Name: 리소스에 이름을 부여 Locator는 변할 수 있지만 Name은 변하지 않는다. Name만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않아서 대부분 URL을 사용한다. [3] URL 문법 해석 (문법) scheme://[userinfo@]host[:port][/path][?quer..

[1] IP(인터넷 프로토콜; Internet Protocol) 지정한 IP 주소(IP Address)에 데이터를 패킷(Packet)이라는 통신 단위로 나눠서 전달한다. IP 패킷은 전송 데이터와 출발지 IP, 목적지 IP 등의 내용을 포함하고 있다. - IP의 한계 비연결성 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷이 전송된다. 비신뢰성 중간에 패킷이 사라질 수 있다. 패킷의 도착 순서가 처음과 달라질 수 있다. 프로그램 구분 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 때 구분이 어렵다. [2] TCP와 UDP TCP/IP 패킷은 출발/목적지 PORT, 전송 제어, 순서, 검증 정보 등이 포함되어 있어 IP 만으로 해결되지 않았던 순서와 관련된 문제가 해결이 된다. - ..