목록이론 (33)
오봉이와 함께하는 개발 블로그
PUT PUT /members/100 HTTP/1.1 Content-Type: application/json { "username": "hello", "age": 20 } 리소스를 완전히 대체한다. 리소스가 있으면 대체 리소스가 없으면 생성 쉽게 이야기해서 덮어버린다 중요한건 클라이언트가 리소스를 식별한다. 클라이언트가 리소스 위치를 알고 URI를 지정한다. 이 부분이 POST와 차이 리소스가 있는 경우 리소스가 없는 경우 리소스가 완전히 대체 PATCH 리소스 부분 변경 PATCH 과정 DELETE 리소스 제거 DELETE 과정 메시지가 서버에 도착하면 서버에서는 리소스를 제거한다. HTTP 메소드의 속성 안전 (Safe Methods) 멱등 (Idempotent Methods) 캐시 가능 (Cache..
HTTP API를 만들어보자. 요구사항 / API URI 설계 회원 목록 조회 /read-member-list 회원 조회 /read-member-by-id 회원 등록 /create-member 회원 수정 /update-member 회원 삭제 /delete-member 위 설계는 좋은 URI 설계일까? URI 설계에서 가장 중요한 것은 리소스 식별이다. API URI(Uniform Resource Identifier) 리소스란? 회원을 등록하고 수정하고 조회하는 것이 리소스가 아니다. 회원이라는 개념 자체가 리소스다. 리소스는 어떻게 식별하는 것이 좋은가? 회원을 등록하고 수정하고 조회하는 것을 모두 배제 회원이라는 리소스만 식별하면 됨. 수정된 설계 요구사항 / API URI 설계 회원 목록 조회 /me..
비 연결성(Connectionless) 클라이언트와 서버의 연결을 유지하는 모델에서는 서로 통신중이 아니더라도 연결을 유지하고 있기 때문에 서버 자원을 지속적으로 소모하고 있다. 하지만, 연결을 유지하지 않는 모델에서는 Request&Response가 끝나면 연결을 끊기 때문에 최소한의 자원만을 사용할 수 있다. HTTP는 기본적으로 연결을 유지하지 않는 모델이며 일반적으로 초 단위 이하의 빠른 속도로 응답한다. 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수 십 개 이하로 매우 작기 때문에 비 연결 특성 덕분에 서버 자원을 매우 효율적으로 사용할 수 있다. 한계 TCP/IP 연결을 새로 맺어야 한다. 3 way handshake에 지속적인 자원 소모 웹 브라우저로 사이트..
모든 것이 HTTP HTTP란 HyperText Transfer Protocol의 약자다. HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML(API) 거의 모든 형태의 데이터 전송 가능 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다. 게임서버 정도는 TCP를 사용함. 역사 HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더X HTTP/1.0 1996년 : 메서드, 헤더 추가 HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전 RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014) HTTP/2 2015년 : 성능 개선 HTTP/3 진행중 : TCP 대신에 UDP 사용, 성능 개선 기반 프로..
URI (Uniform Resource Identifier) URI는 로케이터(locatoer), 이름(name) 또는 둘 다 추가로 분류될 수 있다. URL Resource Locator로 리소스의 위치 자체를 나타낸다. URN Resource Name으로 리소스의 이름을 나타낸다. URL과 URN은 저런 형식으로 생겼다. URL은 보통 우리가 적는 https://xxx.xxx.xxx의 형식이고, URN은 이름을 부여하는 형식이다. 문제는 URN을 사용했을 때 이름을 넣어서 결과가 나오려면 Resource가 매핑이 되어야 하는데, URN 방식으로 사용하면 찾기가 거의 불가능하다. 대부분은 URL을 사용한다. URI 뜻 Uniform 리소스를 식별하는 통일된 방식 Resource 자원, URI로 실별할 ..