| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- 컨테이너
- AWS
- JPA
- @Transactional
- mybatis
- Web
- Routing Key
- dockerhub
- JWT
- CORS
- DI
- Dead Letter Queue
- 지연 로딩
- 쿠버네티스
- Spring Data JPA
- redis
- docker compose
- JdbcTemplate
- 서블릿 컨테이너
- Spring Container
- JPQL
- Spring
- kafka
- 스프링 부트
- 페이징
- docker
- securitycontextholderfilter
- @ComponentScan
- DLQ
- MSA
- Today
- Total
목록Web/HTTP (9)
look-forest
이번 시간에는 캐시와 캐시 관련 헤더에 대해 알아보겠다. 캐시 기본 동작 캐시가 없으면.. 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다 인터넷 네트워크는 매우 느리고 비싸다 → 브라우저 로딩 속도가 느려진다 → 느린 사용자 경험 캐시를 도입하자! 1. 응답 메시지에 cache-control 필드를 추가 2. 응답 결과를 브라우저 캐시에 저장 3. 이후 요청은 브라우저 캐시에서 꺼내쓴다! 캐시 덕분에 캐시 가능 시간 동안 네트워크를 사용하지 않아도 된다!! 그런데 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 받아 캐시를 갱신한다 리소스는 바뀐 게 없는데, 굳이 이런 바보 같은 짓을 해야 할까? 검증 헤더와 조건부 요청 캐시 유효 시간 초과 시 캐시 유효 시간이 ..
앞서 HTTP 메시지는 Start line - Header - Body로 이루어진다고 했다. 2021.05.17 - [Web/HTTP] - HTTP 기본 HTTP 헤더에 들어갈 수 있는 표준 헤더 field가 참 많은데, 오늘은 가장 기본이 되는 것부터 알아보겠다. HTTP Header 개요 표현(Representation) 요청이나 응답에서 전달할 실제 데이터. 리소스를 표현한 것. 왜 표현이라 하는가? HTTP 메시지를 통해 전달할 데이터는 리소스를 HTML, JSON 등으로 '표현'한 것이므로. Representation = Representation Metadata + Representation Data HTTP Body 메시지 본문(message body)을 통해 Representation Da..
상태 코드란? 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (Informational): 요청이 수신되어 처리중 (거의 사용되지 않는다) 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 2xx (Successful) "클라이언트의 요청을 성공적으로 처리했다" 200 OK 201 Created "요청이 성공해서 새로운 리소스가 생성됐다" 생성된 리소스는 응답의 Location 헤더 필드로 식별 202 Accepted "요청이 접수되..
이번 시간에는, 실무에서 앞서 배운 HTTP 메서드를 어떻게 적용하면 좋을지 정리해보겠다. 클라이언트에서 서버로의 데이터 전송 방식 데이터 전달 방식은 크게 2가지 쿼리 파라미터를 통한 데이터 전송 GET / 주로 필터(검색어, 정렬 조건) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH / 회원 가입, 주문, 리소스 등록, 리소스 변경 데이터 전송의 4가지 CASE 정적 데이터 조회 응답 결과를 보통 정적리소스, HTML로 받을 때 사용 동적 데이터 조회 응답 결과를 보통 HTML로 받을 때 사용 HTML Form을 통한 데이터 전송 응답 결과를 보통 HTML로 받을 때 사용 HTTP API를 통한 데이터 전송 응답 결과로 HTML이 아닌 데이터를 전달 받음 쿼리 파라미터 데이터 전송 1..
다음과 같은 회원 정보 관리 API를 만든다고 가정해보자 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URI를 다음과 같이 설계했다. 기능 URI 회원 목록 조회 /read-member-list 회원 조회 /read-member-by-id 회원 등록 /create-member 회원 수정 /update-member 회원 삭제 /delete-member 이것은 좋은 URI 설계일까? 이번 시간에는 URI 설계 기준과 HTTP Method, 그리고 HTTP Method의 속성에 대해서 알아보겠다. URI 설계 기준 URI 설계 기준 = 1. 리소스 식별 2.URI 계층 구조 활용 1. URI(Uniform Resource Identifier)는 이름 그대로 리소스를 식별하는 목적이다. 따..
모든 것이 HTTP다 HTTP: HyperText Transfer Protocol 그러나, 지금은 HTML 뿐만 아니라 TEXT, IMAGE, 영상, 파일 등 거의 모든 형태의 데이터를 HTTP로 전송한다 서버 간에 데이터를 주고 받을 때(API)도 대부분 HTTP를 사용한다 - JSON, XML HTTP 메시지에 모든 것을 전송하는, 지금은 HTTP의 시대다. HTTP 버전 HTTP/0.9 : GET 메서드만 지원, HTTP 헤더X HTTP/1.0 : 메서드, 헤더 추가 HTTP/1.1 : 주로 사용. 대부분의 기능이 들어 있음. HTTP/2 : 성능 개선 HTTP/3 : 성능 개선, TCP 대신에 UDP 사용(UDP 프로토콜 위에 애플리케이션 레벨에서 성능 최적화하여 새로 설계) 왜 이렇게 HTTP가..
URI Uniform Resource Identifier 리소스를 식별하는 통일된 방식 URI? URL? URN? URN 이름만으로 실제 리소스를 찾을 수 있는 방법은 보편화되지 않아 거의 쓸 일이 없다 따라서 URI와 URL은 거의 동일한 의미로 쓰인다고 생각하면 된다. URL 문법 scheme://[userinfo@]host[:port][/path][?query][#fragment] 예) https://www.google.com/search?q=hello&hl=ko scheme: 주로 프로토콜 사용(어떤 방식으로 자원에 접근할 것인가 하는 약속) userinfo: URL에 사용자 정보를 포함해서 인증(거의 사용x) host: 호스트명(도메인명 or IP 주소 직접 사용) port: 접속 포트(일반적으..
왜 HTTP가 중요한가? 앱과 서버의 통신이든 서버와 서버의 통신이든 전부 HTTP 기반 위에서 동작하기 때문이다. 앞으로 실무에 필요한 HTTP 이론의 전체 흐름을 정리하겠다. 먼저 HTTP는 네트워크 프로토콜이므로, 네트워크부터 간략히 복습하겠다. 인터넷 상에서 컴퓨터 간 통신 과정 먼저, 인터넷 프로토콜(IP)이 필요하다 IP의 역할: 라우터를 거쳐 지정한 IP 주소에 Packet 단위로 데이터 전달 클라이언트의 패킷 전달 서버의 패킷 전달 그런데, 인터넷 프로토콜(IP)만으론 부족하다 # IP의 한계 비연결성 패킷을 받을 대상이 없거나, 서비스 불능 상태에도 패킷을 전송한다 대상 서버가 패킷을 받을 수 있는 상태인지 모르기 때문이다 비신뢰성 중간에 패킷이 사라지거나, 패킷 순서가 바뀔 수 있다 프..