목록전체 글 (167)
Hyunebee
• 1xx (Informational): 요청이 수신되어 처리중 • 2xx (Successful): 요청 정상 처리 200 : OK 201 : Created (주로 POST요청 처리후 사용) 202 : Accepted(요청이 접수되었으나 처리가 완료되지 않았음) 204 : No Content(서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음) • 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 Redirection -> 웹 브라우저는 3xx 응답의 결과에 Location Header가 있으면 해당 Location으로 이동 1. 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동 1.1 301 : Moved Permanently - 리다이렉트시 요청..
HTTP API - 컬렉션 POST기반 등록 회원 관리 시스템 (POST 기반) • 회원 목록 /members -> GET • 회원 등록 /members -> POST 클라이언트는 URI의 리소스의 위치를 모른다. • 회원 조회 /members/{id} -> GET • 회원 수정 /members/{id} -> PATCH, PUT, POST • 회원 삭제 /members/{id} -> DELETE 이러한 형식을 컬렉션이라고 한다. 서버가 관리하는 리소스 디렉토리 서버가 리소스의 URI를 생성하고 관리한다. 여기서 컬렉션은 /members 이다. HTTP API 스토어 PUT 기반 등록 • 파일 목록 /files -> GET • 파일 조회 /files/{filename} -> GET • 파일 등록 /file..
HTTP 설계 • 회원 목록 조회 /read-member-list • 회원 조회 /read-member-by-id • 회원 등록 /create-member • 회원 수정 /update-member • 회원 삭제 /delete-member 이것은 좋은 URI 설계가 아니다 리소스 식별이 가장 중요하다. 회원의 등록 수정 조회 등이 리소스가 아니다. URI는 리소스를 식별하기 위해 사용해야지 행위를 알기위해 사용하면 안됨 회원이 리소스인데 메소드를 어떻게 구분할까? -> HTTP Method들이 대신 처리해준다. • 회원 목록 조회 /members • 회원 조회 /members/{id} • 회원 등록 /members/{id} • 회원 수정 /members/{id} • 회원 삭제 /members/{id} HT..
HTTP? HyperText Trabsfer Protocol 거의 모든 형태의 데이터를 전송 가능 TCP : HTTP/1.1(주로 사용) , HTTP/2 UDP: HTTP/3 HTTP의 특징 1. Client - Server 구조 2. 무상태 프로토콜, 비연결성 3. HTTP메세지 4. 단순함, 확장가능 무상태 프로토콜 서버가 클라이언트의 상태를 보존하지 않음(stateless) -> 무상태는 응답 서버를 쉽게 바꿀 수 있다. (수평 확장 유리) -> 클라이언트의 요청이 증가해도 서버를 대거 투입할 수 있다. 한계점 1.모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다. 로그인: 상태 유지 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지 일반적으로는 쿠키와 서버 세션을 사용해서..
URI(Uniform Resource Identifier ) URI는 Locator , Name 또는 둘다 추가로 분류할 수 있다. Uniform : 리소스를 식별하는 통일 된 방식 Resource : 자원(URI로 식별할 수 있는 모든 것) Identifier : 다른 항목과 구분하는데 필요한 정보 URL(Uniform Resource Locator) URN(Uniform Resource Name) URL 분석 https://www.google.com/search?q=hello&hi=ko scheme://[userinfo@]host[:port][/path][?query][#fragment] scheme : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙(http, https, ftp ) userin..
Client -> internet -> server 어떻게 복잡한 인터넷을 통해 서버로 전달하는가?? -> ip 사용 IP(Internet Protocol) Source ip -> Destination ip를 통해서 전송 IP 프로토콜의 한계 비연결성 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송 전송할 대상이 패킷을 받을 수 있는 상태인지 모름 비신뢰성 중간에 패킷이 사라진다면? 패킷이 순서대로 안오면? 모든 패킷이 같은 노드를 타지 않을 수 있음 프로그램 구분 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면?? TCP 프로토콜 IP만으로 해결이 안되던 오류제어 흐름제어 혼잡제어등을 해결할 수 있게 됨 TCP의 특징 1.연결지향(3way handshake-(가상 연결))..
빈 스코프란? 스프링이 빈이 존재 할 수 있는 범위 1. 싱글톤 : 기본 스코프 -> 스프링 컨테이너 생성~ 종료까지 2. 프로토타입: 빈의 생성과 의존관계주입까지의 짧은 시간을 관리 3. 웹 관련 스코프 3.1 request : 웹 요청이 들어오고 나갈때 까지 유지되는 스코프 3.2 session : 웹 세션이 생성되고 종료될때까지 유지 3.3 application : 웹 서블릿 컨텍스트와 같은 범위로 유지 프로토타입 스코프 스프링 컨테이너는 스프링 빈을 싱글톤으로 반환해주기 때문에 항상 같은 인스턴스의 스프링 빈을 반환해준다. 반면에 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 다른 인스턴스를 반환해준다. 위의 그림을 보면 프로토 타입은 스프링 컨테이너의 생성부터 빈의 생성 ..
스프링 빈의 이벤트 라이프 사이클 스프링 컨테이너 생성 -> 스프링 빈생성 -> 의존 관계 주입 -> 초기화콜백 ->사용 -> 소멸전 콜백->스프링 종료 스프링 빈이 생성되고 의존 관계를 주입한뒤 사용을 해야한다 이때 완료를 알려주는게 초기화 콜백이다. 스프링은 크게 3가지 방법으로 생명주기 콜백을 지원한다. 1.인터페이스 InitializingBean, DisposableBean 해당 인터페이스 메소드를 오버라이딩해서 사용 2.설정 정보에 초기화메소드, 종료 메서드 지정 빈에서 정의한 메소드의 이름을 추가해준다. 3. @PostConstruct, @PreDestory(권장) 스프링 기술이 아니라 자바표준기술이다. https://www.inflearn.com/course/%EC%8A%A4%ED%94%84..