본문 바로가기

Dev/HTTP

 (14)
RS) IP(Internet Protocol) IP(Internet Protocol) IP의 역할 지정한 IP 주소(IP address)에 데이터 전달 패킷 이라는 통신 단위로 데이터 전달 IP 패킷 현재 나의 IP(출발지IP, 목적지 IP, 기타 …) 등의 정보를 가진 상태로 구성되어 있다. 위와 같이 이루어진 정보를 토대로 패킷을 인터넷 망에 던진다. 인터넷은 규약이 미리 정해져있기 때문에 노드에서 타고타고 목적지 IP로 도달하게 된다. 목적지에서는 메시지를 받았다는 응답 메시지를 패킷을 통해서 만들어서 노드를 통해 다시 출발지 IP쪽으로 전달한다. IP 프로토콜의 한계 내가 친구한테 던질 떄 출발지 → 목적지로 갈때와 목적지에서 다시 출발지로 올때 서로 다른곳으로 전달될 수 있다. 비연결성 내가 생성해서 만든 패킷을 받을 대상이 없거나, 서비스..
HTTP 메서드 속성 안전(Safe Methods) 멱등(Idempotent Methods) 캐시가능(Cacheable Methods) 안전(Safe) 호출해도 리소스를 변경하지 않는다. GET, HEAD 같은 경우는 호출해도 변경이 일어나지 않기 때문에 안전하다. 그외에 무언가를 바꾸는 것들은 안전하지 않다. 안전의 부가적인 의심 계속 호출하여 로그 같은게 쌓여서 장애가 발생하는 경우도 안전한가? GET을 하던 도중 다른 사용자가 PUT으로 리소스를 변경해 버려도 상관 없을까? 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다! 멱등(Idempotent) f(f(x)) = f(x) 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같은 경우를 말한다 멱등 메서드 GET : 한번 조회하든, 두..
HTTP 메서드 종류 PUT, PATCH 그리고 DELETE 지난 번에 이어서 나머지 메서드도 알아보자! PUT 리소스를 대체한다. (파일의 복사랑 유사) (출처) 기존에 파일이 없으면 새로 넣어주고, 똑같은 파일이 있다면 덮어 쓴다. 리소스가 있으면 대체 리소스가 없으면 생성 쉽게 이야기해서 덮어버린다. 즉, 완전히 대체해버린다. 중요! 클라이언트가 리소스를 식별 클라이언트가 리소스 위치를 알고 URI 지정 POST와의 차이점을 알아두자 아래 그림을 보면 PUT /members/100 HTTP/1.1 → 클라이언트가 구체적인 리소스 전체 경로를 알고있고 URI를 지정한다! → 이 점이 POST와의 차이점이다. → PUT 같은 경우는 클라이언트가 리소스를 식별한다. PUT 리소스가 있는 경우 (출처) username : old로 age를 50이라는 메시지를 담아서..
HTTP 메서드 종류 GET과 POST 주요메서드 리소스 = 리프리젠테이션 GET : 리소스 조회 POST : 요청 데이터 처리, 주로 등록에 사용 PUT : 리소스를 대체, 해당 리소스가 없으면 생성 PATCH : 리소스 부분 변경 DELETE : 리소스 삭제 기타 메서드 HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환 OPTIONS : 대상 리소스에 대한 통신 기능 옵션(메서드)를 설명(주로 CORS에서 사용) CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정 TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 GET 리소스 조회 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지..
HTTP 메서드 = HTTP API HTTP API를 만들기위해 예시로 만들어보자 회원 목록 API를 설계한다고 가정했을 떄 아래와 같은 경우는 올바른 API 설계일까?? (Before) 회원 목록 조회 /read-member-list 회원 조회 /read-member-by-id 회원 등록 /create-member 회원 수정 /update-member 회원 삭제 /delete-member API URI 설계하는데 있어서 가장 중요한 것은 리소스 식별이다! API URI의 고민 리소스의 의미란? 회원을 등록하고 수정하고 조회하는게 리소스가 아니다. ex) 메니랄을 캐라가 리소스가 아니고 미네랄 자체가 리소스다. 위에서는 회원이라는 개념 자체가 바로 리소스 이다. 리소스를 식별하는 방법은 회원을 등록하고 수정 조회하는 것들은 배제하고 회원이..
HTTP의 메시지 HTTP 프로토콜을 통해 응답을 요청하거나 받는 경우 HTTP 메시지의 형태가 넘어온다. 이 메시지를 통해 어떤 정보들이 넘어왔는지 혹은 넘어가는지를 확인하는 것 HTTP의 요청메시지 형태와 응답메시지 형태의 구성은 아래 그림과 같다. (출처) ㅇ 먼저 HTTP의 메시지가 어떤 구조를 가지는지 부터 살펴보자! (출처) 요청메시지의 시작 라인에는 GET, POST 등이 들어간다. 공백 라인은 무조건 존재해야한다. 시작 라인(요청메시지) start-line = request-line(요청메시지일 경우) / status-line(응답메시지일 경우) request-line = method (GET, POST 등) SP(공백) request-target(요청하는 대상의 Path) SP HTTP-version CR..
HTTP의 성격 Connectionless HTTP는 연결을 유지하지 않는 성질을 기본적으로 가지고 있다. 일반적으로 초 단위 이하의 빠른 속도로 응답 수천명이 서비스를 사용해도 실제 동시에 처리하는 요청은 수십개 이하로 매우 작다. 서버 입장에서 봤을 떄는 자원을 효율적으로 사용한다는 장점이 있다. 아래의 그림에서 연결을 유지하는 경우와 유지하지 않는 경우를 알아보자 (참조) HTTP는 연결을 유지하지 않는다!! 연결을 유지하지 않는 HTTP는 서버에게 필요한 요청을 하고 서버측에서는 최소한의 자원만 유지한채 응답을 내려주고 연결을 끊는다. 비연결성의 한계 TCP/IP 연결을 새로 맺어야 하기 떄문에 3 way handshake 시간이 추가로 든다. ex) Syn, Ack 의 연결 요청할 때 HTML 뿐 아니라 자바스크립트, css 등 추가 이..
HTTP의 성질 Stateless Stateless 스테이스리스 라고 불리우는 이것은 HTTP의 대표적인 성질 중의 하나이다. 서버가 클라이언트의 상태를 보존하지 않겠다라는 의미 Stateless의 성질을 알아보기 위해서는 이와 반대되는 Stateful를 비교하여 알아두는 것이 좋다. Stateful의 특징을 알아보기 위해 예를 들어보려고 한다. 아래의 그림은.. 그렇다.. 31가지 아이스크림이다.. 필자가 자주 시켜먹는 아이스크림이다.. 31가지 아이스크림을 방문하게 되었고.. 아래와같이 3명의 직원이 있다고 가정하자.. 실제로도 3명이상 역할을 나누어 일을한다. 상태 유지 Stateful 상태일 경우 손님 : 31가지 아이스크림 파인트로 주세요 직원A : 7900원 입니다. (아이스크림 종류 상태 유지) 신용카드, 현금중에 어떤걸로 ..

티스토리툴바