이시안 개발 블로그

HTTP 헤더 캐시와 조건부 동작 1. 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다 인터넷 네트워크는 매우 느리고 비싸다 브라우저 로딩 속도가 느리다 느린 사용자 경험 2. 캐시 적용 웹 브라우저에서 요청을 하면 서버에서 cache-control을 지정하는 방법으로 캐시를 적용할 수 있다. 웹 브라우저의 캐시 저장소에 60초 동안 유효한 캐시 데이터를 저장한다. 이후 웹 브라우저의 요청은 캐시에서 먼저 데이터를 조회하고 유효하다면 바로 가져올 수 있다. 이 때 캐시의 유효 시간이 초과되었다면 다시 서버로 요청을 보낸다. 응답 결과는 캐시 저장소에 새로 갱신한다. 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다 비싼 네트워크 사용량을 줄일 ..

HTTP 일반 헤더 header-filed = field-name ":" OWS field-value OWS (OWS: 띄어쓰기 허용) field-name은 대소문자 구분 없음 // 요청 헤더 GET /search?q=hello&hl=ko HTTP/1.1 Host: www.google.com // 응답 헤더 HTTP/1.1 200 OK Content-Type: text/html;charset=UTF-8 Content-Length: 3423 용도 HTTP 전송에 필요한 모든 부가정보 표준 헤더가 너무 많음 https://en.wikipedia.org/wiki/List_of_HTTP_header_fields 필요 시 임의의 헤더 추가 가능 helloword: hihi RFC2616(과거) - 폐기됨 HTTP..

HTTP API 만들어보기 요구사항 회원 정보 관리 API 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URI 고민 리소스의 의미 회원을 등록, 수정, 조회하는 게 리소스가 아님 회원이라는 개념 자체가 바로 리소스 리소스를 어떻게 식별하는 게 좋을까? 회원을 등록, 수정, 조회하는 것을 모두 배제 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장 (member > members) API URI 설계 리소스 식별, URI 계층 구조 활용 역할 좋지 못한 URI 좋은 URI 회원 목록 조회 /read-member-list /members 회원 조회 /read-member-by-id /members/{id} 회원 ..

URI와 웹 브라우저 요청 흐름 URI (Uniform Resource Identifier) URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다 Uniform : 리소스를 식별하는 통일된 방식 Resource : 자원, URI로 식별할 수 있는 모든 것 (제한 없음) Identifier : 다른 항목과 구분하는 데 필요한 정보 URL과 URN? URL : 리소스가 있는 위치를 지정 URN : 리소스에 이름을 부여 URN은 이름만으로 실제 리소스를 찾는 방법이 보편화 되지 않아 잘 쓰이지 않는다. URL 전체 문법 scheme://[userinfo@]host[:port][/path][?query][#fragment] https://www.google.com:443/sea..