프로그래밍 끄적끄적

🌳 HTTP 상태코드 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면 클라이언트는 상위 상태코드로 해석해서 처리 ex. 299라면 성공인거구나~ 451이라면 클라이언트에서 보낼 때 잘못되었구나~ .. 🍃 2xx - 성공 : 요청 정상 처리 ▪ 200 OK: 요청 성공 ▪ 201 Created: 요청 성공해서 새로운 리소스가 생성됨 생성된 리소스는 응답의 Location 헤더 필드로 식별 ▪ 202 Accepted: 요청이 접수되었으나 처리가 완료되지 않음 배치 처리 같은 곳에서 사용 ▪ 204 No Content: 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 예를 들어, save 버튼의 경우 본문을 다시 받을 필요가 없고, 눌러도 같은 화면을 유지해야 함 결과 내..

🌳 HTTP API 설계 예시 HTTP API - 컬렉션 ▪ POST 기반 등록 (ex. 회원 관리 API 제공) HTTP API - 스토어 ▪ PUT 기반 등록 (ex. 정적 컨텐츠 관리, 원격 파일 관리) HTTP API - FORM 사용 ▪ 웹 페이지 회원 관리 (GET, POST만 가능) 🍃 POST 기반 등록 API 설계 (회원 관리 시스템) ▪ 회원 목록 /members -> GET ▪ 회원 등록 /members -> POST ▪ 회원 조회 /members/{id} -> GET ▪ 회원 수정 /members/{id} -> PATCH, PUT, POST ▪ 회원 삭제 /members/{id} -> DELETE POST 신규 자원 등록 특징 ▪ 클라이언트는 등록될 리소스의 URI를 모른다. ▪ 서..

🌳 클라이언트에서 서버로 데이터 전송 🍃 데이터 전송 방법 1. 쿼리 파라미터를 통한 데이터 전송 ▪ GET (주로 검색어/정렬 필터) 2. 메시지 바디를 통한 데이터 전송 ▪ POST, PUT, PATCH ▪ 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 🍃 4가지 예시 상황 1. 정적 데이터 조회 GET /static/star.jpg HTTP/1.1 Host: localhost:8080 서버는 경로에 있는 리소스를 단순히 전달 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 조회 가능 2. 동적 데이터 조회 GET /search?q=hello&hl=ko HTTP/1.1 Host: www.google.com 주로 검색, 게시판 목록에서 정렬 필터 조회 조건을 줄여주는 필터, 조회 결과를..

🌳 HTTP API 🍃 API URI 설계 다음과 같이 짜는게 좋은 URI일까? ▪ 회원 목록 조회: read-member-list ▪ 회원 조회: read-member-by-id ▪ 회원 등록: create-member ▪ 회원 수정: update-member ▪ 회원 삭제: delete-member URI에서 Resource의 의미는 뭘까? 회원을 등록하고 수정하고 조회하는 것 X, 회원 그 자체가 리소스 O 따라서 등록/수정/조회라는 기능 모두 필요 없고, 회원이라는 리소스만 식별하게 하면 된다. * 참고로 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용을 권장한다. (member X, members O) 이런 도출로 다시 URI를 짜보면, ▪ 회원 목록 조회: /members ▪ 회원 조회: /..

🌳 HTTP HTML, TXT, IMAGE, 음성, 영상, 파일 JSON, 티 등 거의 모든 것을 HTTP로 전송할 수 있다. 🍃 HTTP의 특징 1. 클라이언트 서버 구조 ▪ Request Response 구조 ▪ 클라이언트: 서버에 요청을 보내고 응답을 대기, 서버: 요청에 대한 결과를 만들어서 응답 ▪ 클라이언트와 서버를 개념적으로 분리했다는 것에서 이점이 존재한다. ▪ 서버는 데이터 로직에 집중하고 클라이언트는 UI를 나타내는 것이 집중할 수 있기 때문에 각자 독립적으로 진화를 할 수 있다. 2. 무상태 프로토콜(stateless) stateless는 서버가 클라이언트의 이전 상태를 보존하지 않는다. 그 반대로 stateful이 있는데 비유를 해보자. 매장에 가서 하나의 물건을 살 때, state..

🌳 URI (Uniform Resource Identifier) 🍃 URI, URL, URN URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다. URL은 리소스의 위치, URN은 리소스에 이름을 부여한 것이다. 위치는 변할 수 있지만 이름은 변하지 않는다. (예. 어떤 책의 isbn URN) 하지만 URN 만을 가지고 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않았기 때문에 잘 사용하지 않는다. URI 뜻 ▪ Uniform: 리소스를 식별하는 통일된 방식 ▪ Resource: 자원, URI로 식별할 수 있는 모든 것 ▪ Identifier: 다른 항목과 구분하는데 필요한 정보 🍃 URL URL은 아래와 같은 구조를 가진다. scheme://[userinfo@]h..

🌳 IP (Internet Protocol) : 인터넷 환경에서의 통신 규약 지정한 IP 주소에 데이터를 전달하며 패킷이라는 통신 단위로 데이터를 전달한다. IP 패킷 정보 🍃 IP 프로토콜의 한계 1. 비연결성 송/수신자가 데이터 전송을 위해 서로 연결될 필요가 없기 때문에 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송한다. (대상 서버가 패킷을 받을 수 있는지 여부를 송신자는 모른다.) 2. 비신뢰성 흐름에 관여하지 않기 때문에 전송한 패킷의 손상 여부를 송/수신자가 알 수 없으며 패킷 전달 순서를 보장하지 않는다. 즉, 전송 과정에서 패킷이 손상될 수도 있고, 같은 호스트에서 전송한 패킷의 순서가 뒤죽박죽이 될 수도 있고, 같은 패킷이 두 번 전송될 수도 있으며, 아예 패킷이 사라질 ..

🌳 스프링 스코프 1. 싱글톤 ▪ 기본 스코프로, 스프링 컨테이너의 시작부터 종료까지 유지된다. ▪ 하나의 인스턴스만 생성되기 때문에, 언제든지 같은 인스턴스의 스프링 빈을 반환함을 보장한다. 2. 프로토타입 (@Scope("prototype")) ▪ 빈 생성과 의존관계 주입까지만 관리한다. ▪ 클라이언트가 요청하는 "시점에" 새로운 빈을 생성하고 초기화하여 반환한다. ▪ 따라서 요청할 때마다 새로 생성되기 때문에 서로 다른 인스턴스를 가진다. (getBean도 이에 해당함) ▪ 이는 각 클라이언트마다 필드값을 따로 관리할 수 있다는 말로 해석할 수 있음 ▪ 빈을 반환한 이후에는 프로토타입 빈을 관리하지 않는다. 따라서 종료 메서드도 호출되지 않으며, 클라이언트가 관리해야 한다. 3. 웹 관련 스코프 ▪..