HTTP

클라이언트 -> 서버 데이터 전송 방식이전 HTTP 메서드 포스팅을 통해 알 수 있는 사실이 있다. HTTP 를 통해 데이터를 전달하는 방식은 크게 두가지 있는데, 이는 다음과 같다- 쿼리 파라미터를 통한 데이터 전송 -> GET 을 통한 정렬 필터 사용- 메시지 바디에 직접 데이터를 담아 전송 -> POST, PUT, PATCH 등을 통해 사용HTTP API 설계 예시- HTTP API - POST 기반으로 컬렉션(리소스)를 등록- HTTP API - 스토어 -> PUT 기반의 등록을 통한 정적 컨텐츠, 원격 파일 관리- HTML FORM 사용 -> 웹 페이지 회원 관리, GET || POST 1탄의 요구사항에 HTTP 메서드를 통한 구분HTTP 메서드는 행위 -> 동사, members 는 리소스즉 우..

이전에서도 봤듯이 우리는 행위를 구분하기 위해서는 HTTP 메서드를 이용해야한다.먼저 HTTP 메서드를 실제 적용하기 전에 간단히 HTTP 메서드들에 대해 먼저 작성하겠다.HTTP 메서드 종류GET : 리소스 조회POST : 요청 데이터 처리PUT : 리소스 대체PATCH : 리소스 부분 변경DELETE : 리소스 삭제+) HEAD, OPTIONS, CONNECT, TRACE 등GET - 주세요 ~GET 메서드는 리소스를 조회하고, 서버에 전달하고 싶은 데이터는 쿼리 파라미터(쿼리 스트링)을 통해 전달한다.요청 메시지 바디에 데이터를 담을 순 있지만 지원하지 않는 곳이 많다.GET 요청을 통해 100번째 회원정보를 요청하면 다음과 같은 JSON으로 응답을 받을 수 있다.POST - 이 데이터로 처리해주세..

요구사항 V0회원 정보 관리 API 를 만들어야한다. 요구 사항은 다음과 같다.1. 회원 목록 조회2. 회원 조회3. 회원 등록4. 회원 수정5. 회원 삭제API URI 설계 절망편일단 최대한 직관적으로 설계해본다.1. 회원 목록 조회 -> /read-member-list2. 회원 조회 -> /read-member-by-id3. 회원 등록 -> /create-member4. 회원 수정 -> /update-member5. 회원 삭제 -> /delete-member최대한 직관적으로 작성해보았는데, 이게 과연 최선의 설계일까?우리가 중요하게 생각해야할 것은 리소스를 식별할 수 있어야한다는 점이다 !어떤 방식을 적용하면 좋을까?먼저 리소스가 뭔지 리마인드 해보자.회원을 등록하고 수정하고 조회하는게 리소스가 아니..

HTTP 프로토콜은 기본적으로 연결을 유지하지 않는 모델이다.정확히 말하면 여기서 말하는 연결은 TCP/IP의 3 Way Hand Shaking 을 통한 논리적 연결 확립을 의미한다.그렇다면 왜 HTTP는 Connectionless, 즉 비 연결성을 지향하는 것일까? 이를 위해 먼저 연결성 모델이 어떤식으로 작동되는지 알아야한다.Connectionful - 연결을 유지하는 모델 예시위 이미지처럼 연결을 유지하는 모델은 각 클라이언트별로 모든 논리적 연결로를 확립해둔다.이로인해 서버는 각 클라이언트별 세션, 소켓 등 개인별로 스레드를 부여해야하기 때문에 서버 자원의 소모가 심해지고, 메모리 예외가 터지며 서버가 중지 될 수도 있다. Connectionless - 비연결성 모델비 연결성 모델은 다음과 같이 ..

Stateless(무상태 프로토콜)무상태 프로토콜의 주요 특징은 서버가 클라이언트의 상태를 보존하지 않는다는 점이다.이 덕분에 서버를 확장하기 쉬우나, 클라이언트가 요청을 보낼때마다 추가적인 데이터 전송이 필요하다.반대로 Stateful 하다는 것은 서버가 클라이언트이 상태를 보존하는 것이겠죠?? Stateful 의 예시 시나리오1) 클라이언트가 서버에 상품A 가격 조회 요청 -> 서버는 클라이언트에게 상품A의 가격을 응답2) 클라이언트는 해당 상품의 구매 개수 요청 -> 서버는 이전 상품A를 기억하고 있기 때문에, 구매 개수와 가격을 연산처리 후 값을 응답 및 결제 수단 선택 요청 폼 전송3) 클라이언트는 해당 상품의 결제 수단 선택 후 서버에 전송 -> 서버는 이전 상품 A, 구매 개수, 가격을 기억..

URL, URI, URN의 세가지 큰 주제는 URI의 하위 범주라고 생각하면 편하다.URI (Uniform Resource Identifier)URI 는 쉽게 생각해서 URL + URI의 조합(정확히 말하면 두개로 분류 된다)이다.-> URL 의 L 은 Loctaion, 즉 리소스의 위치를 의미하고, URN 의 N은 Name, 즉 리소스의 이름을 의미한다.URN은 생각보다 방식이 보편화 되어 있지 않고, URN은 변해도 URL은 변하지 않기 때문에 URL와 URI를 거의 같은 의미로 칭한다. Google URL로 분석해보기URL의 전체 문법은 다음과 같다. 그럼 이제 구글 URL을 통해 좀더 알아보자 . scheme(A.K.A 프로토콜)scheme 부분에는 http, https, ftp 등의 네트워크 ..

Cookie 없이 HTTP 통신시 발생하는 문제Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고 HTTP 요청시 서버로 전달 Set-Cookie 헤더를 통해 서버에서 클라이언트로 전달위 사진처럼 웹에 접속 -> 로그인 과정을 진행한다고 가정하자. 클라이언트와 서버는 서로 상태를 유지하지 않는다 (Stateless)HTTP는 무상태(stateless) 프로토콜이므로 3Way Hand Shake 를 통해 클라이언트와 서버가 요청과 응답을 한번 주고 받으면 연결을 해제한다. 즉, 클라이언트가 다시 서버에 HTTP 요청을 보내도 서버는 이게 이전 클라이언트인지 아닌지 기억하지 못한다. 그렇다면 HTTP 요청을 보낼 때마다 GET 의 쿼리 파라미터로 사용자의 정보를 전송하는 방식은 어떨까?위와 같은 대안..

4xx (Client Error)- 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청 수행 불가- 오류 원인은 클라이언트에게 있다- 클라리언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패한다 400 Bad Request클라이언트가 잘못된 요청을 해서 서버가 요청 처리 불가한 상태.요청 구문, 메시지 등의 형식을 잘못 입력하거나, API 스펙이 맞지 않을 때 발생하기 때문에, 클라이언트가 요청 내용을 다시 검토하고 보내야한다. 401 Unauthorized클라이언트가 해당 리소스에 대한 인증이 필요하다.401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명해야한다. 403 Forbidden서버가 요청을 이해했지만 승인 거부.주로 인증 자격 증명..

3xx (Redirection)요청을 완료하기 위해 유저 에이전트의 추가 조치 필요여기서 Redirction 은 간단하게, 3xx 응답의 결과에 Location 헤더가 존재하면, Location 위치로 자동 이동하는 방식을 의미한다.(리다이렉트)1. 예를 들어 기존에 /event 페이지를 통해 진행한 이벤트 이력이 있는데, 사용자들이 북마크를 해두고 이벤트가 끝난 시기에 GET /event URI 로 접속 시도2. 서버는 301 코드와 함께 Location 으로 새롭게 운영중인 이벤트 사이트의 URI 제공3. 클라이언트는 301 코드를 확인하고 획득한 Location 정보를 가지고 해당 URI 에 대한 GET 메서드 새로 생성후 전송4. 새 이벤트 페이지 에서 200 코드로 접속 OKRedirection..