프로그래밍 끄적끄적

🌳 캐시 기본 동작 🍃 캐시가 없는 경우 star.jpg 이미지를 처음 요청했을 경우 서버는 1.1M를 전송함 (헤더 0.1M, 바디 1.0M이라고 가정) 또 다시 똑같은 요청을 했을 경우 서버는 똑같이 1.1M를 전송함 이런 방식의 문제점 ▪ 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 함 ▪ 인터넷 네트워크는 매우 느리고 비쌈 ▪ 브라우저 로딩 속도가 느림 = 느린 사용자 경험 🍃 캐시를 적용한 경우 star.jpg 이미지를 처음 요청했을때 서버는 기존 1.1M HTTP 메시지에 캐시와 관련된 정보를 추가하여 전송함 ex) cache-control: max-age=60 //60초 동안 캐시가 유효함 이를 받은 웹 브라우저는 캐시 저장소에 이 응답 결과를 캐시로 저장함 60..

🌳 HTTP 헤더 🍃 필드 구성방식 field-name: field-value 🍃 HTTP 헤더 용도 HTTP 전송에 필요한 모든 부가 정보 ex) 메시지 바디의내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 ▪ 표준 헤더 필드 https://en.wikipedia.org/wiki/List_of_HTTP_header_fields 🍃 HTTP 헤더 분류 ▪ General 헤더: 메시지 전체에 적용되는 정보 ex) Connection: close ▪ Request 헤더: 요청 정보 ex) User-Agent: Mozilla/5.0 ▪ Response 헤더: 응답 정보 ex) Server: Apache ▪ Entity 헤더: 엔티티 바디 정보 ex) Content-Ty..

🌳 HTTP 상태코드 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면 클라이언트는 상위 상태코드로 해석해서 처리 ex. 299라면 성공인거구나~ 451이라면 클라이언트에서 보낼 때 잘못되었구나~ .. 🍃 2xx - 성공 : 요청 정상 처리 ▪ 200 OK: 요청 성공 ▪ 201 Created: 요청 성공해서 새로운 리소스가 생성됨 생성된 리소스는 응답의 Location 헤더 필드로 식별 ▪ 202 Accepted: 요청이 접수되었으나 처리가 완료되지 않음 배치 처리 같은 곳에서 사용 ▪ 204 No Content: 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 예를 들어, save 버튼의 경우 본문을 다시 받을 필요가 없고, 눌러도 같은 화면을 유지해야 함 결과 내..

🌳 HTTP API 설계 예시 HTTP API - 컬렉션 ▪ POST 기반 등록 (ex. 회원 관리 API 제공) HTTP API - 스토어 ▪ PUT 기반 등록 (ex. 정적 컨텐츠 관리, 원격 파일 관리) HTTP API - FORM 사용 ▪ 웹 페이지 회원 관리 (GET, POST만 가능) 🍃 POST 기반 등록 API 설계 (회원 관리 시스템) ▪ 회원 목록 /members -> GET ▪ 회원 등록 /members -> POST ▪ 회원 조회 /members/{id} -> GET ▪ 회원 수정 /members/{id} -> PATCH, PUT, POST ▪ 회원 삭제 /members/{id} -> DELETE POST 신규 자원 등록 특징 ▪ 클라이언트는 등록될 리소스의 URI를 모른다. ▪ 서..

🌳 클라이언트에서 서버로 데이터 전송 🍃 데이터 전송 방법 1. 쿼리 파라미터를 통한 데이터 전송 ▪ GET (주로 검색어/정렬 필터) 2. 메시지 바디를 통한 데이터 전송 ▪ POST, PUT, PATCH ▪ 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 🍃 4가지 예시 상황 1. 정적 데이터 조회 GET /static/star.jpg HTTP/1.1 Host: localhost:8080 서버는 경로에 있는 리소스를 단순히 전달 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 조회 가능 2. 동적 데이터 조회 GET /search?q=hello&hl=ko HTTP/1.1 Host: www.google.com 주로 검색, 게시판 목록에서 정렬 필터 조회 조건을 줄여주는 필터, 조회 결과를..

🌳 HTTP API 🍃 API URI 설계 다음과 같이 짜는게 좋은 URI일까? ▪ 회원 목록 조회: read-member-list ▪ 회원 조회: read-member-by-id ▪ 회원 등록: create-member ▪ 회원 수정: update-member ▪ 회원 삭제: delete-member URI에서 Resource의 의미는 뭘까? 회원을 등록하고 수정하고 조회하는 것 X, 회원 그 자체가 리소스 O 따라서 등록/수정/조회라는 기능 모두 필요 없고, 회원이라는 리소스만 식별하게 하면 된다. * 참고로 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용을 권장한다. (member X, members O) 이런 도출로 다시 URI를 짜보면, ▪ 회원 목록 조회: /members ▪ 회원 조회: /..

🌳 HTTP HTML, TXT, IMAGE, 음성, 영상, 파일 JSON, 티 등 거의 모든 것을 HTTP로 전송할 수 있다. 🍃 HTTP의 특징 1. 클라이언트 서버 구조 ▪ Request Response 구조 ▪ 클라이언트: 서버에 요청을 보내고 응답을 대기, 서버: 요청에 대한 결과를 만들어서 응답 ▪ 클라이언트와 서버를 개념적으로 분리했다는 것에서 이점이 존재한다. ▪ 서버는 데이터 로직에 집중하고 클라이언트는 UI를 나타내는 것이 집중할 수 있기 때문에 각자 독립적으로 진화를 할 수 있다. 2. 무상태 프로토콜(stateless) stateless는 서버가 클라이언트의 이전 상태를 보존하지 않는다. 그 반대로 stateful이 있는데 비유를 해보자. 매장에 가서 하나의 물건을 살 때, state..

🌳 URI (Uniform Resource Identifier) 🍃 URI, URL, URN URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다. URL은 리소스의 위치, URN은 리소스에 이름을 부여한 것이다. 위치는 변할 수 있지만 이름은 변하지 않는다. (예. 어떤 책의 isbn URN) 하지만 URN 만을 가지고 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않았기 때문에 잘 사용하지 않는다. URI 뜻 ▪ Uniform: 리소스를 식별하는 통일된 방식 ▪ Resource: 자원, URI로 식별할 수 있는 모든 것 ▪ Identifier: 다른 항목과 구분하는데 필요한 정보 🍃 URL URL은 아래와 같은 구조를 가진다. scheme://[userinfo@]h..