twocowsong

데이터 전송 클라이언트에서 서버로 데이터 전송시 크게 2가지 방법이다. 1. 쿼리 파라미터를 통한 데이터 전송 - GET, 주로 정렬 필터(검색어) 2. 메시지 바디를 통한 데이터 전송 - POST, PUT, PATCH (회원가입, 상품주문, 리소스등록, 변경) 예시 4가지 상황) 1. 정적 데이터 조회 - 이미지, 정적 텍스트 문서 2. 동적 데이터 조회 - 주로 검색, 게시판 목록에서 정렬 필터(검색어) 3. HTML Form을 통한 데이터 전송 4. HTTP API를 통한 데이터 전송 -정적 데이터 조회 저장된 이미지 경로를 요청하면 서버에서는 이미지를 내려준다. 조회는 GET을 사용하며 정적데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회가 가능하다. 동적 데이터 조회 쿼리파라미..

HTTP 메서드의 속성 • 안전(Safe Methods) • 멱등(Idempotent Methods) • 캐시가능(Cacheable Methods) 안전 (Safe) 호출해도 리소스를 변경하지않는다. 여러번 호출했을경우 변경이 일어나는것은 안전하지않다. GET은 호출해도 안전하고, POST,DELETE는 안전하지않다. 멱등(Idempotent) 한번 호출하든 두번 호출하든 100번 호출하든 결과가 똑같다. 멱등메서드 GET은 한번 조회하든, 100번조회를 하든 똑같같기에 멱등하다. PUT은 완전히 대체하기에 몇번을 시도하든 똑같다. DELETE는 같은 데이터를 한번 삭제하든 100번 삭제하든 똑같다. POST는 멱등이아니다. 두번호출해서 결제가 2번 일어날수도있다. 멱등 활용 활용 : 자동 복구 메커니즘..

PUT, PATCH, DELETE PUT : 리소스가 있으면 대체, 리소스가 없으면 생성, 쉽게 이야기 하면 덮어버림 - 예를들면 파일이라고 생각하면됨. 파일을 새로운곳에 복사하면 생성이지만 같은 이름이 있으면 덮어버리는 경우. 완전히 대체 해버림. PATCH : 리소스 부분 변경. PUT은 전체변경이 되는 반면 PATCH는 보낸값만 변경됨으로 리소스의 부분만 수정하고싶을때는 PATCH를 사용하면된다. 단 PATCH를 지원하지않는 서버가 있음으로 그럴때는 POST를 사용하면된다. DELETE : 리소스를 삭제하고싶은경우.

HTTP 메서드 HTTP API HTTP API를 만들어보자. 요구사항은 아래와 같다. • 회원 목록 조회 • 회원 조회 • 회원 등록 • 회원 수정 • 회원 삭제 요구사항에 맞는 URI을 만들때 가장 중요한것은 리소스 식별이다. 리소스란? • 회원을 등록하고 수정하고 조회하는게 리소스가 아니다! 예) 미네랄을 캐라 -> 미네랄이 리소스 • 회원이라는 개념 자체가 바로 리소스다. • 리소스를 어떻게 식별하는게 좋을까? - 회원을 등록하고 수정하고 조회하는 것을 모두 배제 • 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑 리소스만 식별하게된다면 아래와 같아진다. • 회원 목록 조회 • 회원 조회 • 회원 등록 • 회원 수정 • 회원 삭제 리소스와 행위를 분리하며 가장 중요한것은 리소..

HTTP 메세지 HTTP 메세지의 구조는 그림과 같다. 시작라인, 헤더, 공백(무조건 있어야함), body로 구성되어있다. 예)HTTP 요청 메시지를 보면 GET 방식의 /search?q=hello&hl=ko로 path 가 구성되어 있으며 HTTP1.1 프토로콜로 시작라인 구성되어있으며 헤더정보, 공백, Body(그림에는 없음)로 구성되어있다. 응답메세지에서는 시작라인이 다르다. HTTP1.1 프로토콜이나오고 200 OK (뒤에 자세히 다루겠습니다.)가 나온뒤 헤더값이 출력, 후 공백라인이 무조건 나오며 메시지 바디 영역이 나옵니다. 응답메세지는 RFC 공식 스펙에도 자세히 나와있습니다. 이제 각각 라인에 대해서 자세히 보겠습니다. 시작 라인(start-line)은 request-line, status-..

비연결성 비연결성(connectionless) • HTTP는 기본이 연결을 유지하지 않는 모델 -(클라이언트가 서버에게 요청 후 서버는 응답 한 뒤 연결을 끈어버린다.) • 일반적으로 초 단위의 이하의 빠른 속도로 응답 • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이 하로 매우 작음 • 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다. • 서버 자원을 매우 효율적으로 사용할 수 있음 -(클라이언트랑 연결이 되어있지않기때문에 서버적 부담이 크지않다) 비연결성 단점 • TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가 -(매번 클라이언트 요청마다 서버랑 연결을 새롭게 하기때문에) • 웹 브라우저로 사이트를 요청하면 HTM..

무상태 프로토콜 스테이스리스(Stateless) - 서버가 클라이언트의 상태를 보존하지 않는다. 장점 : 서버 확장성 높음 , 단점 : 클라이언트 추가 데이터 전송 만약 상태를 유지하게된다면 아래와 같은 상황이된다. // ========================================= 상태 유지 - Stateful • 고객: 이 노트북 얼마인가요? • 점원: 100만원 입니다. • 고객: 2개 구매하겠습니다. • 점원: 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요? • 고객: 신용카드로 구매하겠습니다. • 점원: 200만원 결제 완료되었습니다. 너무 평범한 대화라 이상할것이 없다. 만약 점원이 바뀐다면? // ===================================..

클라이언트 서버 구조 HTTP는 클라이언트가 요청메세지를 전송후 대기한다. 서버에 대한 응답결과를 받아서 사용한다. 비즈니스 로직과 데이터는 서버에 두고 클라이어언트는 UI에 집중한다. 이렇게되면 클라이언트와 서버는 각각 발전할수있게 된다.