캐시 기본 동작 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 매우 느리고 비싸다. 브라우저 로딩 속도가 느리다. 느린 사용자 경험 캐시 적용 첫 번째 요청을 했을 때 응답 결과를 캐시에 저장한다. 이후 들어온 요청에 대해서는 캐시 유효 시간을 검증하고 데이터를 캐시에서 조회한다. 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르다. 빠른 사용자 경험 캐시 시간 초과 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다. 이때 다시 네트워크 다운로드가 발생한다. 검증 헤더와 조건부 요청1 (Last-Modified & if..
인프런 강의/김영한 Http
Http 헤더 용도 Http 전송에 필요한 모든 부가정보 ex) 메시지 바디 내용, 메시지 바디 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보... 필요시 임의의 헤더 추가 가능 ex) hello: world Http 표준 1999년 RFC2616 -> 폐기됨 2014년 RFC7230~7235 등장 RFC723x 변화 Entity -> 표현(Representation) 표현 = 표현 메타데이터 + 표현 데이터 HTTP BODY (RFC7230) 메시지 본문(body)를 통해 표현 데이터 전달 메시지 본문 = payload 표현은 요청이나 응답에서 전달할 실제 데이터 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공 ex) 데이터 유형(JSON, html, xml...), 데이터 ..
200 200 OK 201 Created: 요청 성공해서 새로운 리소스가 생성됨 202 Accepted: 요청이 접수되었으나 처리가 완료되지 않았음 204 No Content: 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 ex) 웹 문서 편집기에서 save 버튼 눌렀을 때 거의 200, 201 정도만 사용함 300 요청을 완료하기 위해 유저 에이전트(클라이언트 프로그램 - 웹 브라우저)의 추가 조치 필요 리다이렉션 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트) 리다이렉션의 종류 영구 리다이렉션 (301, 308) 일시적인 리다이렉션 (302, 307, 303) 리소스의 URI가 일시적으로 변경 따라서 ..
클라이언트 -> 서버로 데이터 전송 쿼리 파라미터를 통한 데이터 전송 GET으로 주로 사용 주로 정렬 필터(검색어)를 쓸 때 사용 메시지 바디를 통한 데이터 전송 Post, Put, Patch 회원가입, 상품 주문, 리소스 등록, 리소스 변경 등 정적 데이터 조회 이미지, 정적 텍스트 문서 불러올 때 조회는 get 사용 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 동적 데이터 조회 주로 검색, 게시판 목록에서 정렬 필터(검색어) 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용 조회는 get 사용 get은 쿼리 파라미터를 사용해서 데이터를 전달 HTML Form 데이터 전송 (POST) Form 태그를 이용해 POST 전송 - 저장 메시지 바디에 ..
http API 설계 API URI 설계 uri 설계에서 가장 중요한 것은 리소스 식별! 리소스란? 회원을 등록하고 수정하고 조회하는 게 리소스가 아니다. 회원이라는 개념 자체가 리소스다. 리소스 식별 회원을 등록하고 수정, 조회하는 것을 모두 배제하고 회원이라는 리소스만 식별하면 된다. -> 회원이라는 리소스를 uri에 매핑 ex) read-member-by-id -> /members/{id} (조회) /members/{id} (등록) /members/{id} (삭제)... 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장 URI는 리소스만 식별 리소스와 해당 리소스를 대상으로 하는 행위를 분리 리소스(명사): 회원 행위(동사): 조회, 등록, 삭제, 변경... 행위(메소드)는 http 메소드로 ..
Http (HyperText Transfer Protocol) HyperText: html http 메시지에 모든 것을 전송 http의 역사 기반 프로토콜 http 특징 Client Server 구조 Stateful & Stateless 무상태 프로토콜 (Stateless) 상태 유지 (Stateful) 서버가 클라이언트의 이전 상태(문맥 context)를 보존 -> Stateful 상태에서 점원이 중간에 바뀌는 경우 무상태 (Stateless) 점원에게 필요한 정보를 그때그때 넘겨줌 -> 점원이 바뀌어도 문제가 발생하지 않음 클라이언트에서 필요한 정보를 데이터에 담아 넘겨주기 때문에 서버가 중간에 바뀌어도 문제가 발생하지 않는다. Stateful vs Sateless Stateful 항상 같은 서버가 ..
URI Uniform: 리소스를 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier: 다른 항목과 구분하는데 필요한 정보 URL: Uniform Resource Locator -> 리소스가 있는 위치를 지정 URN: Uniform Resource Name -> 리소스에 이름을 부여 -> 위치는 변할 수 있지만 이름은 변하지 않는다. URN 이름만으로 실제 리소스를 찾을 수 있는 방법은 보편화되지 않음(거의 URL을 사용) schme 주로 프로토콜 사용 프로토콜: 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙 ex) http(80 포트), https(443 포트), ftp 등 포트는 생략 가능 https는 http에 강력한 보안 추가 use..
인터넷 통신 IP (인터넷 프로토콜) 인터넷 프로토콜의 역할 지정한 IP 주소(IP Address)에 데이터 전달 패킷이라는 통신 단위로 데이터 전달 IP 프로토콜의 한계 비연결성: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송 비신뢰성: 중간에 패킷이 사라지거나 순서대로 안 오는 경우 프로그램 구분: 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상인 경우 -> 이런 문제를 해결하기 위해 TCP, UDP를 입혀서 사용 TCP & UDP 패킷: 수하물 덩어리 TCP TCP 특징 전송 제어 프로토콜 연결지향 - TCP 3 way handshake(가상 연결) 데이터 전달 보증: 패킷이 유실되는 경우 알려줌 순서 보장: TCP 패킷에 순서 정보가 있기 때문에 가능 신뢰할 수 있는 프..