twocowsong

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에 집중한다. 이렇게되면 클라이언트와 서버는 각각 발전할수있게 된다.

HTTP 기본 모든것이 HTTP HTTP (HyperText Transfer Protocol)에 담아서 모든것을 전송한다. HTML, TEXT, 이미지, 음성, 영상, 파일, JSON, XML 거의 모든 형태의 데이터 전송이 가능하다. 서버간의 데이터를 주고 받을 때도 대부분 HTTP를 사용한다. HTTP 역사 • HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X • HTTP/1.0 1996년: 메서드, 헤더 추가 • HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전 -> HTTP/1.1에 가장 많은 기능이 추가되어있으며 그 뒤 버전은 성능 추가버전이다. -> RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014) ->..