내가 기억하려고 만든 블로그 내가 기억하려고 만든 블로그

1. 캐시 기본 동작 캐시가 없을 때 첫 번째 요청 1.1M의 이미지를 전송 두 번째 요청 첫 번째 요청에서 1.1M의 이미지를 전송했지만 또다시 전송 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 매우 느리고 비싸다. 브라우저 로딩 속도가 느리다. 캐시 적용 첫 번째 요청 1.1M의 이미지를 전송 캐시 저장 두 번째 요청 두 번째 요청부터 캐시를 먼저 확인 캐시 덕분에 캐시 가능 시간 동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르다. 세 번째 요청 - 캐시 시간 초과 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다. 이때 다시 네트워크 다운로드가 발생한다..

1. 표현 Content-Type : 표현 데이터의 형식 Content-Encoding : 표현 데이터의 압축 방식 Content-Language : 표현 데이터의 자연 언어 Content-Length : 표현 데이터의 길이 표현 헤더는 전송, 응답 둘다 사용 Content-Type 표현 데이터의 형식 설명 미디어 타입, 문자 인코딩 예) text/html; charset=utf-8 application/json image/png Content-Encoding 표현 데이터 인코딩 표현 데이터를 압축하기 위해 사용 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제 예) gzip deflate identity Content-Language 표현 데이터의..

상태 코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (Informational) : 요청이 수신되어 처리 중 2xx (Successful) : 요청 정상 처리 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요 4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함 1xx (Informational) 요청이 수신되어 처리 중 거의 사용하지 않으므로 생략 2xx (Successful) 클라이언트의 요청을 성공적으로 처리 200 OK 201 Created 202 Accepted 204 No Content 1. 200 OK 요청 성공..

1. 클라이언트에서 서버로 데이터 전송 데이터 전달 방식은 크게 2가지 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터(검색어) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 4가지 상황 1. 정적 데이터 조회 이미지, 정적 텍스트 문서 2. 동적 데이터 조회 주로 검색, 게시판 목록에서 정렬 필터(검색어) 3. HTML Form을 통한 데이터 전송 회원 가입, 상품 주문, 데이터 변경 4. HTTP API를 통한 데이터 전송 회원 가입, 상품 주문, 데이터 변경 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax) 1. 정적 데이터 조회 쿼리 파라미터 미사용 정리 이미지, 정적 텍스트 문서 조회는 GET 사용 정적 데이터..

1. PUT, PATCH, DELETE PUT 리소스를 대체 리소스가 있으면 대체 리소스가 없으면 생성 쉽게 이야기해서 덮어버림 폴더에 파일을 넣는 것과 비슷하다고 보면 됨 폴더에 파일을 넣을 때 파일이 없으면 생성, 있으면 덮어쓰기 중요! 클라이언트가 리소스를 식별 클라이언트가 리소스 위치를 알고 URI 지정 POST와 차이점 POST : /members -> 클라이언트는 어디에 만들어지는지 모름 PUT : /members/100 -> 클라이언트가 지정함 리소스가 있는 경우1 리소스가 있는 경우2 리소스가 없는 경우1 리소스가 없는 경우2 주의! 리소스를 완전히 대체한다1 주의! 리소스를 완전히 대체한다2 PUT은 리소스를 덮어버리기 때문에 수정하기 어려움 그래서 PATCH를 사용 PATCH 리소스 부..

1. HTTP API를 만들어 보자 요구사항 회원 정보 관리 API를 만들어라. 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URI 설계 URI(Uniform Resource Identifier) 회원 목록 조회 / read-member-list 회원 조회 / read-member-by-id 회원 등록 / create-member 회원 수정 / update-member 회원 삭제 / delete-member 이것은 좋은 URI 설계일까? 가장 중요한 것은 리소스 식별 API URI 고민 리소스의 의미는 뭘까? 회원을 등록하고 수정하고 조회하는 것이 리소스가 아니다! 예) 미네랄을 캐라 -> 미네랄이 리소스 회원이라는 개념 자체가 바로 리소스다. 리소스를 어떻게 식별하는 것이 좋을까?..

HTTP(HyperText Transfer Protocol) HTTP 특징 클라이언트 서버 구조 무상태 프로토콜(스테이스리스) 비연결성 HTTP 메시지 단순함, 확장 가능 1. 클라이언트 서버 구조 Request Response 구조 클라이언트는 서버에 요청을 보내고, 응답을 대기 서버가 요청에 대한 결과를 만들어서 응답 2. 무상태 프로토콜(스테이스리스(Stateless)) 서버가 클라이언트의 상태를 보존X 장점 : 서버 확장성 높음(스케일 아웃) 단점 : 클라이언트가 추가 데이터 전송 Stateful, Stateless 차이 상태 유지 - Stateful 고객 : 이 노트북 얼마인가요? 점원 : 100만원 입니다. 고객 : 2개 구매하겠습니다. 점원 : 200만원 입니다. 신용카드, 현금 중 어떤 것..

1. URL URI? URL? URN? 주소와 이름 URI Uniform : 리소스 식별하는 통일된 방식 Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier : 다른 항목과 구분하는데 필요한 정보 URL, URN URL - Locator : 리소스가 있는 위치를 지정 URN - Name : 리소스에 이름을 부여 위치는 변할 수 있지만, 이름은 변하지 않는다. urn:isbn:8960777331 (어떤 책의 isbn URN) URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음 URL 분석 전체 문법 scheme://[userinfo@]host[:port][/path][?query][#fragment] https://www.google.com:44..