이 또한 지나가리라

상태코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx(Informational) 요청이 수신되어 처리중 2xx(Successful) 요청 정상 처리 3xx(Redirection) 요청 완료를 위한 추가 행동 필요 4xx(Client Error) 클라이언트 오류. 잘못된 문법등으로 서버가 요청을 수행할 수 없음 5xx(Server Error) 서버 오류. 서버가 정상 요청을 처리하지 못함 만약 모르는 상태 코드가 나타나면? ㅁ 클라이언트는 상위 상태코드로 해석해서 처리 2xx - 성공 클라이언트의 요청을 성공적으로 처리 상태 코드 내용 비고 200 OK 요청 성공 201 Created 요청 성공해서 새로운 리소스가 생성됨 202 Accepted 요청이 접수되었으나 처리가 완료되지 않..

1. 클라이언트에서 서버로 데이터 전송 2. HTTP API 설계 예시 1. 클라이언트에서 서버로 데이터 전송 1-1. 데이터 전달 방식 2가지 ㅁ 쿼리 파라미터를 통한 데이터 전송 - GET - 주로 정렬 필터(검색어) ㅁ 메시지 바디를 통한 데이터 전송 - POST, PUT, PATCH - 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 1-2. 4가지 상황 ㅁ 정적 데이터 조회 - 이미지, 정적 텍스트 문서 - 조회는 GET 사용 ㅁ 동적 데이터 조회 - 쿼리 파라미터 사용 - 주로 검색, 게시판 목록에서 정렬 필터 ㅁ HTML FORM 을 통한 데이터 전송 - multipart/form-data: 바이너리 데이터 전송 시 사용. 다른 종류의 여러 파일과 폼의 내용을 함께 전송 가능 ㅁ HTTP..

1. HTTP API를 만들어보자 2. HTTP 메서드 - GET, POST 3. HTTP 메서드 - PUT, PATCH, DELETE 4. HTTP 메서드의 속성 1. HTTP API를 만들어보자 API 이름 API URI(Uniform Resource Identifier) 리소스 식별, URI 계층 구조 활용 회원 목록 조회 /read-member-list /members 회원 조회 /read-member /members/{id} 회원 등록 /create-member /members/{id} 회원 수정 /update-member /members/{id} 회원 삭제 /delete-member /members/{id} * 리소스 식별이 가장 중요하다. * 계층 구조상 상위를 컬렉션으로 보고 복수 단어 사..

목차 1. 모든 것이 HTTP 2. 클라이언트 서버 구조 3. Stateful, Stateless 4. 비 연결성 5. HTTP 메시지 모든 것이 HTTP HTTP(HyperText Transfer Protocol) 1. html, text 2. image, audio, video, file 3. JSON, XML(API) 4. 거의 모든 형태 데이터 전송 가능 5. 서버 간에 데이터를 주고 받을 때도 대부분 HTTP 사용 기반 프로토콜 TCP: HTTP/1.1, HTTP/2 UDP: HTTP/3 HTTP 특징 1. 클라이언트 서버 구조 2. 무상태 프로토콜(stateless), 비연결성 3. HTTP 메시지 4. 단순함, 확장 클라이언트 서버 구조 1. Request Response 구조 2. 클라이언..

URI (Uniform Resource Identifier) URI는 로케이터, 이름 또는 둘 다 추가로 분류될 수 있다. URI 의미 Uniform: 리소스를 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것 Identifier: 다른 항목과 구별하는 데 사용 URL, URN 의미 URL - Locator: 리소스 위치를 지정 URN - Name: 리소스에 이름을 부여 위치는 변하지만 이름은 변하지 않는다. urn:isbn:8960777331 (어떤 책의 isbn URN) URL 분석 scheme://[userinfo@]host[:port][/port][/path][?query][#fragment] 문법 예시: https://google.com/search?q=hello&..

인터넷 네트워크 인터넷 통신 IP (Internet Protocol) 지정한 IP 주소에 데이터 전달 패킷이라는 통신 단위로 데이터 전달 IP패킷 정보 - 출발지IP, 목적지IP, 기타... 클라이언트 패킷 전달 서버 패킷 전달 IP 프로토콜의 한계 비연결성 패킷을 받을 대상이 없거나 서비스 불능 상태에도 패킷 전송 - 클라이언트는 대상 서버가 패킷을 받을 수 있는 상태인지 알 수 없다. 비신뢰성 중간에 패킷이 소실된 경우 패킷이 비순차적으로 전달될 경우 - 용량이 너무 큰 파일의 경우 분할하여 전달할 때 인터넷이 그때 그때 마다 가장 효율적인 노드를 선택해서 전달을 한다. 프로그램 구분 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 경우 TCP, UDP IP프로토콜의 문제점을 해결하기..

LAN과 WAN의 경계 그리고 Broadcast Broadcast는 라우터로 구분 지어진 Broadcast 영역에 LAN 상으로 묶여진 모든 네트워크에게 전하는 통신이다. 이는 네트워크 효율을 떨어뜨린다. 반대개념은 unicast로 1:1 통신을 의미한다. Broadcast의 범위(범위를 최소화 하는 것이 중요하다.) Boradcast주소라는 매우 특별한 주소가 존재한다. (MAC, IP 모두 존재) Broadcast는 MAC(48비트)의 입장에서 주소가 모두 1로 구성되어 있다. F = 1111(2) -> FF-FF-FF-FF-FF-FF-FF-FF LAN에서 보내는 데이터 단위인 Frame이 있다. Frame에는 header 단이 존재한다. 주소는 2개가 있다.(출발지, 목적지) 1개의 Distribu..

1. FIRST_HALF 와 JULY 테이블의 외래키인 FLAVOR로 JOIN을 해준다. 2. 주문량이 많은 순서대로 3가지의 맛을 출력해야 하기 때문에 SUM을 해주고 내림차 정렬 후 LIMIT로 잘라준다 3. 위에서 구한 값을 서브쿼리로 잡아주고 컬럼 FLAVOR를 출력해준다. SELECT FLAVOR FROM ( SELECT t1.FLAVOR, SUM(t1.TOTAL_ORDER) AS ORDERS FROM FIRST_HALF t1 INNER JOIN JULY t2 ON t1.FLAVOR = t2.FLAVOR GROUP BY t1.FLAVOR ORDER BY ORDERS DESC LIMIT 3 ) t3;

AOP 관련 설정을 하고 테스트를 하는데 bean initial에러가 발생했다. AOP쪽 소스만 주석처리하면 코드는 문제없이 동작했기 때문에 bean 등록 문제는 아니었다. AOP 라이브러리 설정 및 버전 체크 확인 org.springframework spring-aop ${org.springframework-version} org.aspectj aspectjrt ${org.aspectj-version} org.aspectj aspectjweaver ${org.aspectj-version} AOP 소스 쪽 문제도 아니었다. 결국 에러 로그의 가장 밑단을 확인하고 구글링을 해보았다. https://stackoverflow.com/questions/75116023/unable-to-make-protected..

https://school.programmers.co.kr/learn/courses/30/lessons/131124 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr 문제에서는 가장 많은 리뷰 수를 가진 회원 정보에 관한 데이터를 추출하라고 요구하였습니다. 제가 문제에 접근한 방식은 아래와 같습니다. 1. 리뷰 테이블에 존재하는 ROW 수를 회원ID 별로 COUNT한다. 2. 리뷰 테이블의 ROW수를 회원ID로 구분한 COUNT와 1에서 구한 COUNT의 최대값과 같은 MEMBER_ID를 SELECT한다. 3. 도출한 MEMBER_ID를 WHERE절로 감싸 ..