yeon's blog

HTTP 요청 파라미터 - 쿼리 파라미터, HTML Form 클라이언트에서 서버로 요청 데이터를 전달할 때는 주로 다음 3가지 방법을 사용한다. 1. GET - 쿼리 파라미터 ?username=hello&age=20 메시지 바디 없이, URL의 쿼리 파라미터에 데이터를 포함하여 전달 검색, 필터, 페이징 등에서 많이 사용하는 방식 2. POST - HTML Form Content-Type: application/x-www-form-urlencoded 메시지 바디에 쿼리 파라미터 형식으로 전달: username=hello&age=20 HTML Form 사용 3. HTTP message body에 데이터를 직접 담아서 요청 HTTP API에서 주로 사용 JSON, XML, TEXT 등 데이터 형식은 주로 J..

HTTP 요청 - 기본, 헤더 정보 조회 애노테이션 기반의 스프링 컨트롤러는 다양한 파라미터를 지원한다. HTTP 요청 헤더 정보를 조회하기 위한 코드를 작성한 후, @Slf4j 로깅 라이브러리를 이용해 각 요청에 대한 로그를 남겨 확인해보았다. *로그 관련 글 첨부 https://hyeyeon-ii.tistory.com/66 RequestHeaderController 전체코드 package hello.springmvc.basic.request; import jakarta.servlet.http.HttpServletRequest; import jakarta.servlet.http.HttpServletResponse; import lombok.extern.slf4j.Slf4j; import org.spri..

🌱 캐시의 기본 동작 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 매우 느리고 비싸다. 브라우저의 로딩 속도가 느리다. 이로 인해 느린 사용자 경험이 발생한다. 캐시 적용 cache-control header를 작성해 일정 시간동안 캐시에 유지할 수 있다. 이렇게 캐시를 적용하게 되면, 일정 시간 동안 같은 요청을 보낼 때, 네트워크를 통해서 결과를 받아오지 않고 브라우저 캐시에 접속해서 결과를 받아오기 때문에 이 과정에서 시간이 크게 단축된다. 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르다. 빠른 사용자 경험을 만들어준다. 웹 브라우저 이용시..

🌱 HTTP 헤더 개요 HTTP 헤더 header-field = field-name ":" OWS field-values OWS (OWS: 띄어쓰기 허용) HTTP 전송에 필요한 모든 부가정보를 넣는다. 예를 들어 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리정보.. 등... 표준 헤더는 굉장히 많고, 필요 시 임의의 헤더 추가가 가능하다. 과거의 HTTP 헤더 분류는 생략! 🌱 표현 #표현: 메타 데이터와 표현 데이터를 합친 것 HTTP BODY - RFC7230 메시지 본문을 통해 요청이나 응답에서 전달할 실제 데이터를 표현 데이터 전달 하는데 사용한다. 메시지 본문을 페이로드라고 부른다. Content-Type 클라이언트랑 서버 간에 실제 데이터를..

🌱 HTTP 상태코드 소개 상태코드: 클라이언트가 서버로 요청을 보냈을 때, 요청의 처리 상태를 응답해주는 기능 👉 1xx (Informational): 요청이 수신되어 처리중 ➡️ 거의 사용되지 X 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 🌱 2xx - 성공 200 OK 클라이언트의 요청이 정상적으로 처리되었음을 알리는 상태코드 201 Created POST로 요청을 보내면 리소스 URI를 서버에서 생성하는 상태코드 HTTP Header Loca..

🌱 HTTP API 설계 예시 API 설계 - POST 기반 등록 👉 회원 관리 시스템 1. 회원 목록: /members ➡️ GET 2. 회원 등록: /members ➡️ POST 3. 회원 조회: /members/{id} ➡️ GET 4. 회원 수정: /members/{id} ➡️ PATCH, PUT, POST 5. 회원 삭제: /members/{id} ➡️ DELETE 신규 자원 등록 특징 클라이언트는 등록될 리소스의 URI를 모른다. 회원 등록 /members → POST POST /members 서버가 새로 등록된 리소스 URI를 생성해준다. HTTP/1.1 201 Created Location: /member/100 컬렉션(Collection) 서버가 관리하는 리소스 디렉토리 서버가 리소스의 ..

🌱 클라이언트에서 서버로 데이터 전송 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터(검색어) 주로 GET 방식으로 많이 사용하고 검색어로 검색할 때, 게시판 리스트에 정렬 조건을 넣을 때 쿼리 파라미터를 이용해서 많이 사용한다. 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 클라이언트에서 서버로 전송할 때 HTTP 메시지 바디를 통해서 데이터를 전송한다. POST, PUT, PATCH 방식으로 주로 사용한다. 회원가입을 하려면 클라이언트에서 데이터를 서버로 전송해야 한다. 그 다음에 상품을 주문하거나 새로운 리소스를 등록하거나 리소스를 변경할 때 사용한다. 클라이언트에서 서버로 데이터 전송할 때 4가지 상황 1. 정적 데이터 ..

🌱 HTTP Method의 속성 1. 안전(Safe Methods) 호출해도 리소스를 변경하지 않는다. GET은 단순히 조회만 하기 때문에 안전하다. 한번 호출해도 여러번 호출해도 변경이 일어나지 않아서 안전하다. POST, PUT, PATCH, DELETE는 안전하지 않다. 만약에 그래도 계속 호출해서 서버에서 로그가 계속 쌓게되서 서버 장애가 일어날 때 → 안전은 그런 부분까지 고려하지 않는다. 안전은 해당 리소스만 고려하기 때문이다. 2-1. 멱등(Idempotent Methods) 클라이언트가 서버에 같은 요청을 여러번 해도 결과는 동일하다. GET은 한 번 조회하든 두 번 조회하든 같은 결과로 조회된다. PUT은 결과를 대체하기 때문에 같은 요청을 여러 번 해도 최종 결과는 동일하다. DELET..

🌱 HTTP Method - 메서드 종류 HTTP 주요 메서드 종류 GET : 리소스를 조회 POST : 요청 데이터를 담아서 처리 PUT : 리소스를 대체, 해당 리소스가 없으면 생성 PATCH : 리소스 부분 변경 DELETE : 리소스 삭제 HTTP 기타 메서드 종류 HEAD : GET과 동일하지만 메시지 부분을 제외하고 상태 줄과 헤더만 반환 OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)를 설명 (주로 CORS에서 사용) CONNECT: 대상 자원으로 식별되는 서버에 대한 터널 설정 TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 * CONNECT, TRACE는 거의 사용하지 X 1. GET: 리소스 조회 특정한 리소스를 가져오도록 요청한다. GET 요청..

🌱 HTTP API를 만들어보자 요구사항 및 API URI 설계 👉 회원 정보 관리 API 설계 1. 회원 목록 조회 : /read-member-list 2. 회원 조회 : /read-member-by-id 3. 회원 등록 : /create-member 4. 회원 수정 : /update-member 5. 회원 삭제 : /delete-member → 요구사항 기반으로 API를 만들게 되면 위와 같이 현업에서 잘못된 API URI 설계를 한다. API URI 설계 분리 👉 리소스: 회원✨✨✨ 행위: 조회, 등록, 수정, 삭제 → 리소스 식별 ‼️ API URI 설계를 할 때 리소스와 해당 리소스를 대상으로 하는 행위를 분리해야 한다. 회원이라는 리소스만 식별하고 회원 리소스를 URI에 매핑을 하면 된다. A..