yeon's blog

🌱 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..

🌱 HTTP 메시지 HTTP 메시지 구조 HTTP 요청 메시지 GET /search?name=minsu&lan=ko HTTP/1.1 -> 시작 라인 Host: http://www.google.com -> 헤더 -> 공백 라인 method: GET, POST, PUT, DELETE 등 서버가 수행해야 할 동작 지정 GET: 서버에게 리소스 조회 POST: 서버가 리소스 요청 내역 처리 request-target 보통 절대 경로로 ‘/’로 시작하고 쿼리를 합침 *http://...?x=y 같이 다른 유형의 경로지정 방법도 있음 HTTP-version HTTP 응답 메시지 HTTP/1.1 200 OK -> 시작 라인 Content-Type: text/html;charset=UTF-8 Content-Length..

🌱 비 연결성 (connectionless) 연결을 유지하는 모델 단점 - 클라이언트가 급증한 경우 서버에 과부하가 걸려 서버가 다운될 수 있음 연결을 유지하지 않는 모델 비연결성: 요청이 필요할 때마다 그때그때 연결해서 바로 끊는 형태 장점 - 최소한의 자원 유지(효율적) 단점 TCP/IP 연결을 새로 맺을 때마다 3 way handshake 시간이 추가가 되서 클라이언트 입장에서는 느림 웹 브라우저로 사이트를 요청하면 HTML, CSS, Javascript, 추가 이미지 등 수많은 자원이 함께 다운로드 할 때 연결하고 끊고를 반복하므로 비효율적 극복 - 지속 연결(Persistent Connection)로 문제 해결 지속 연결: HTTP에서 TCP/IP 연결을 일정 기간 열어두고 여러 요청을 하는 것..

🌱 Stateful, Stateless 상태유지: 서버가 클라이언트의 상태 보존 단점 - 중간에 서버에 장애가 나면, 다른 서버에서 처음부터 다시 시작해야 함 고객: 이 노트북 얼마인가요? 점원: 100만원 입니다. (노트북 상태 유지) 고객: 2개 구매하겠습니다. 점원: 200만원입니다. 신용카드, 현금 중에 어떤걸로 구매하시겠어요? (노트북, 2개 상태 유지) 고객: 신용카드로 구매하겠습니다. 점원: 200만원 결제 완료되었습니다. (노트북, 2개, 신용카드 상태 유지) → 점원이 바뀌지 않는 경우에는 문제가 발생하지 않지만, 고객: 이 노트북 얼마인가요? 점원A: 100만원 입니다. 고객: 2개 구매하겠습니다. 점원B: ? 무엇을 2개 구매하시겠어요? 고객: 신용카드로 구매하겠습니다. 점원C: ? ..

🌱 클라이언트 서버 구조 Request Response 구조 클라이언트는 서버에 요청을 보내고, 응답을 대기 서버는 요청에 대한 응답을 만들어 응답 역할 원래는 클라이언트와 서버가 하나였다가 개념적으로 분리가 되면서 클라이언트는 UI, 사용성에 집중하고 서버는 비즈니스 로직이랑 데이터에 집중하게 되었다. 이슈가 발생해도 서로의 역할이 달라 이슈에 대한 영향을 미치지 않고 독립적으로 이슈를 대응하면서 진화할 수 있다.

🌱 모든 것이 HTTP HTTP(HyperText Transfer Protocol) HTTP: 하이퍼 텍스트, 즉 문서 간에 정보를 주고 받을 수 있는 프로토콜 HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML 등 모든 형태의 데이터를 담아 전송 가능 지금은 HTTP 시대!! HTTP 역사 HTTP/0.9 (1991년) : GET 메서드만 지원, HTTP 헤더X HTTP/1.0 (1996년) : 메서드, 헤더 추가 HTTP/1.1 (1997년) : 가장 많이 사용하고 우리에게 가장 중요한 버전이다. HTTP/2 (2015년) : 성능 개선 HTTP/3 (진행중) : TCP 대신에 UDP 사용, 성능 개선 HTTP 기반 프로토콜 TCP: HTTP/1.1, HTTP/2 UDP: HTT..