프로젝트 진행 중 OpenAI API를 연동하는 과정에서, RestTemplate과 WebClient 두 가지 방법의 차이점과 각각의 장단점에 대해 고민하게 되었습니다. 스프링 애플리케이션에서 HTTP 요청을 처리하는 방법으로 RestTemplate과 WebClient가 있습니다. 스프링 5.0 이전까지는 RestTemplate이 주로 사용되었으나, 스프링 5.0 이후로는 WebClient가 새로 도입되어 현재는 WebClient를 사용하는 것이 권장되고 있습니다. 그럼 RestTemplate과 WebClient는 각각 어떤 특징을 가지고 있으며, 왜 WebClient를 권장하는지 자세히 살펴보겠습니다.  RestTemplateRestTemplate 이란?스프링 3.0에서부터 지원하는 RestTempla..

캐시 기본 동작만약 캐시가 없는 경우라면?웹  브라우저에서 별 파일을 요청한다면 헤더와 바디를 서버에서 요청을 한다.그리고 두번째로 요청을 해도 똑같은 파일을 보내야 한다.그럼 너무 비효율적이고 문제점이 있다데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 함.인터넷 네트워크는 매우 느리고 비쌈.브라우저 로딩 속도가 느림.느린 사용자 경험 그렇다면 캐시를 적용하게 된다면?웹 브라우저에서 서버에 요청을 하면 서버에서 캐시의 유효한 시간값을 가지고 그 응답결과를 캐시에 저장하게 됨.그렇게 두번째 요청시 네트워크 요청이 필요없이 그냥 캐시에 조회가 가능하게 함. 캐시를 적용하게 된다면캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨비싼 네트워크 사용량을 줄일 수있음, 브라우..

HTTP 헤더header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)field-name은 대소문자 구문 없음용도HTTP 전송에 필요한 모든 부가정보예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보...표준 헤더가 너무 많음https://en.wikipedia.org/wiki/List_of_HTTP_header_fields필요시 임의의 헤더 추가 가능helloworld: hihi분류 - RFC2616(과거)헤더 분류General 헤더: 메시지 전체에 적용되는 정보, 예) Connection: closeRequest 헤더: 요청 정보, 예) User-Agent: Mozilla/5.0 (Maci..

상태 코드클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능1xx (Informational): 요청이 수신되어 처리중2xx (Successful): 요청 정상 처리3xx (Redirection): 요청을 완료하려면 추가 행동이 필요4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함만약 모르는 상태 코드가 나온 경우? 클라이언트가 인식할 수없는 상태코드를 서버가 반환하면?클라이언트는 상위 상태코드로 해석해서 처리미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨예)• 451 ??? -> 4xx (Client Error)599 ??? -> 5xx (S..

클라이언트에서 서버로 데이터 전송은 2가지 방법이 있다. 첫번째 쿼리 파라미터를 통한 데이터 전송GET주로 정렬 필터 (검색어)두번째 메시지 바디를 통한 데이터 전송POST , PUT , PATCH회원 가입, 상품 주문, 리소스 등록, 리소스 변경 클라이언트에서 서버로 데이터 전송의 4가지 상황을 들어보겠다. 정적 데이터 조회이미지 , 정적 텍스트 문서조회는 GET 을 사용정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 동적 데이터 조회주로 검색, 게시판 목록에서 정렬 필터(검색어)조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용조회는 GET 사용GET은 쿼리 파라미터 사용해서 데이터를 전달 HTML Form 데이터 전송HTML Form submit시..

HTTP API를 만들어보자.요구사항으로 회원 정보 관리 API를 만들어라 회원 목록 조회회원 조회회원 들록회원 수정회원 삭제그렇다면 API URI 설계는 다음과 같다.회원 목록 조회 /read-member-list회원 조회 /read-member-by-id회원 등록 /create-member회원 수정 /update-member회원 삭제 /delete-member하지만 이건 좋은 URI 설계가 아니다! 가장 중요한 것은 리소스 식별 이다. 그렇다면 역기서 리소스는 무엇을 의미하는걸까?회원을 등록하고 수정하고 조회하는 리소스가 아니라 -> 회원이라는 개념 자체가 바로 리소스그러면 리소스는 어떻게 식별해?회원을 등록하고 수정을 배제하고 회원이라는 리소스만 식별하면 된다. 즉 회원 리소스를 URI에 매핑  다..

HTTP 여러 역사들이 있지만 우리에게 가장 중요한 HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전!!!!!기반 프로토콜TCP: HTTP/1.1, HTTP/2UDP: HTTP/3현재 HTTP/1.1 주로 사용HTTP/2, HTTP/3 도 점점 증가HTTP 특징클라이언트 서버 구조무상태 프로토콜(스테이스리스), 비연결성HTTP 메시지단순함, 확장 가능클라이언트 서버 구조 Request Response 구조클라이언트는 서버에 요청을 보내고, 응답을 대기서버가 요청에 대한 결과를 만들어서 응답Stateless 무상태 프로토콜스테이스리스(Stateless)서버가 클라이언트의 상태를 보존X장점: 서버 확장성 높음(스케일 아웃)단점: 클라이언트가 추가 데이터 전송Stateful, State..

URI(Uniform Resource Identifier)"URI는 로케이터(locator), 이름(name) 또는 둘다 추가로 분류될 수 있다"Uniform: 리소스 식별하는 통일된 방식Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)Identifier: 다른 항목과 구분하는데 필요한 정보URL: Uniform Resource Locator : Locator: 리소스가 있는 위치를 지정URN: Uniform Resource Name : Name: 리소스에 이름을 부여위치는 변할 수 있지만, 이름은 변하지 않음urn:isbn:8960777331 (어떤 책의 isbn URN)URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음 URL 전체 문법scheme://[use..

인터넷 네트워크의 종류는 총 5가지로 나눈다.인터넷 통신IP(Internet Protocol)TCP, UDPPORTDNS 그렇다면 인터넷에서 복잡한 메세지망을 가지고 있는 컴퓨터 둘은 어떻게 통신할까?복잡한 인터넷망을 메시지를 보내기 위해선 제일 먼저 이 인터넷 프로토콜이라는 IP가 있어야 된다.IP 인터넷 프로토콜 역할지정한 IP 주소(IP Address)에 데이터 전달패킷(Packet)이라는 통신 단위로 데이터사진과 같이 복잡한 노드를 뚫고 클라이언트와 서버사 패킷들을 전송하지만 IP는 한계점이 있다. IP 프로토콜의 한계● 비연결성패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송● 비신뢰성중간에 패킷이 사라지면?패킷이 순서대로 안오면?●  프로그램 구분같은 IP를 사용하는 서버에서 통신하는..