캐시 기본 동작 캐시가 없으면 첫 요청에서 이미지를 다운받고 똑같은 요청임에도 다시 다운을 받아야 한다. 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 매우 느리고 비싸다. 브라우저 로딩 속도가 느리다. 느린 사용자 경험 캐시 적용 첫 요청에서 이미지를 다시 요청하자. 응답 헤더에 아래가 포함되어있다. cache-control: max-age=60 캐시가 유효한 시간이 60초라는 말이다. 응답 결과를 브라우저 캐시에 저장한다. 두 번째 요청부터는 캐시를 먼저 확인한다. 캐시가 있으면 유효 시간 내라면 캐시에서 가져와서 사용한다. 즉, 네트워크를 사용하지 않아도 된다. 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르다. 빠른 사용자 경험 다음 요청에서 캐시 시간이

HTTP 헤더 HTTP 전송에 필요한 모든 부가정보 ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐피 관리 정보 ... 표준 헤더가 너무 많음 필요시 임의의 헤더 추가 가능 RFC2616 (과거) General 헤더: 메시지 전체에 적용되는 정보 Request 헤더: 요청 정보 Response 헤더: 응답 정보 Entity 헤더: 엔티티 바디 정보 HTTP BODY RFC2616 (과거) 메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (informational): 요청이 수신되어 처리중 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 유청을 수행할 수 없음 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 인식할 수 없는 상태코드라면 상위 상태코드로 해석한다. 즉, 299 -> 2xx 1xx (Informational) 요청이 수신되어 처리 중 실무에서 거의 사용하지 않으므로 생략 2xx (Successful) 클라이언트의 요청을 성공적으로 처리 200 OK 요청 성공 201 Cretaed 요청 성공해서 새로운 리소스가 생성됨 202 Accepted 요청이 접수되었으나 처리가 완료되지 않았음

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

HTTP API를 만들어보자 URI 설계에 가장 중요한 것은 리소스이다. 회원을 등록, 수정, 조회하는 것이 리소스가 아니다. 회원이라는 개념 자체가 리소스이다. 회원이라는 리소스만 식별하면 된다 => 회원 리소스를 URI에 매핑 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장 (member => members) 리소스와 행위를 분리하자. 리소스는 명사, 행위는 동사 주요 메서드 GET: 조회 POST: 등록 PUT: 자체를 바꿈, 없으면 생성 PATCH: 부분 변경 DELETE: 삭제 기타 메서드 HEAD: GET과 같지만, 헤더만 반환 OPTIONS: 통신 가능 옵션, CORS에서 사용 잘 안씀 (* CONNECT: 대상 리소스으로 식별되는 서버에 대한 터널 설정) (* TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행) GET 조회 전달하

모든 것이 HTTP HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 거의 모든 형태의 데이터 전송 가능 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 HTTP 역사 HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 없음 HTTP/1.0 1996년: 메서드, 헤더 추가 HTTP/1.1 1997년: 가장 많이 사용 HTTP/2 2015년: 성능 개선 HTTP/3 진행 중: TCP 대신 UDP 사용, 성능 개선 TCP: HTTP/1.1, HTTP/2 UDP: HTTP/3 HTTP/1.1 주로 사용 HTTP/2, HTTP/3 도 점점 증가 크롬 개발자 도구 네트워크 탭에서 프로토콜을

URI Uniform Resource Identifier URI? URL? URN? URL: 리소스 위치 URN: 리소스 이름 URI: 리소스 식별자 URI 뜻 Uniform: 리소스 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것 (제한없음) Identifier: 다른 항목과 구분하는데 필요한 정보 URL, URN 뜻 위치는 변할 수 있다. 이름은 변하지 않는다. URN은 책의 isbn과 같은 것이다. 이름만으로 실제 리소스를 찾는 방

인터넷 통신 클라이언트가 서버와 통신을 하려면 인터넷 즉, IP(인터넷 프로토콜)이 필요하다. 클라이언트 IP: 100.100.100.1 => 서버 IP: 200.200.200.2 클라이언트인 내가 서버로 메시지를 보내보자. IP 역할 대상 IP 주소에 데이터 전달 패킷(packet)이라는 통신 단위로 데이터 전달 패킷 정보에는 나의 IP, 서버 IP, 메시지 내용 등을 담는다. 인터넷에 있는 노드들이 이 패킷을 주고받으면서 해당 서버를 찾아 전달한다. 서버도 마친가지로 패킷에 서버 IP, 나의 IP, 'OK'라는 메시지 등을 담고 인터넷 노드들이 이 패킷을 주고받으면서 나의 IP를 찾아 전달한다. 인터넷 망이 복잡하니, 나 => 서버 와 서버 => 나 과정이 다를 수 있다. IP 한계 비연결성 패킷을 받을 대상이 없을 때에도 패킷 전송 서비스 불능 상태여도 패킷 전송 비신뢰성