모든 개발자를 위한 HTTP 9

모든 개발자를 위한 HTTP 웹 - 7. HTTP 헤더1 - 인증, 쿠키

1. 웹 브라우저가 id, password를 담아 서버에 로그인을 요청함 2. 서버는 id, password 검증에 성공하면, 해당 사용자에 대한 sessionId(쿠키)를 생성함 3. 서버는 Set-Cookie에 sessionId를 담아 '웹 브라우저'에 '로그인 성공'을 응답함 4. 웹 브라우저는 '쿠키 저장소'에 sessionId(쿠키)를 저장함 5. 이후 웹 브라우저가 쿠키에 접근가능한 도메인에 요청을 보낼 때마다 자동으로 쿠키 저장소에서 꺼낸 sessionId(쿠키)를 Cookie에 담아 서버에 요청을 보냄 6. 서버는 sessionId(쿠키)의 유효성을 검사해 클라이언트를 식별함

모든 개발자를 위한 HTTP 웹 - 6. HTTP 상태코드

-> 201은 리소스를 새로 저장하고 저장된 경로를 Location에 포함해서 반환하며 '응답 메세지'에 본문을 첨부해도 된다. -> 204는 No content. '응답 메세지'에 본문을 첨부하면 안된다. 저장이 성공했고 결과 데이터를 반환할 일이 없을 때 사용하면 된다. 화면은 계속 유지해야 하기 때문에 -> 200: 새롭게 업데이트한 페이지를 보여줘야 할 때 : GET, PATCH -> 201 : 리소스를 신규로 생성했을 때 : POST -> 204 : 사용자에게 보여지는 페이지를 바꾸지 않고 리소스를 업데이트 할 때 : PUT 1. 302 - 메서드가 GET으로 변할 수 있음 2. 307 - 메서드가 변하면 안됨 3. 303 - 메서드가 GET으로 변경됨 -> 현실적으로 307, 303을 권장하지..

모든 개발자를 위한 HTTP 웹 - 5. HTTP 메서드 활용 - HTTP API 설계 예시

1. 리소스를 식별하여 리소스만으로 URI를 설계한다. 2. 문서, 컬렉션, 스토어로 해결하기 어려운 상황의 경우 컨트롤 URI를 사용한다. -> 주로 '컬렉션'을 많이 사용하고 파일/게시판 같은 경우에 '스토어'를 사용할 수 있다. -> 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스를 실행할 때, 컨트롤 URI를 사용한다. Q. 데이터 전송의 경우 2가지 방식중 어떤 방식을 실무에서 선호하는가? 1. HTML Form이 메인, 필요에 따라 AJAX(HTTP)를 통한 PUT, PATCH,DELETE 활용 2. 애초에 AJAX(HTTP API)를 메인으로 활용 -> 두 방식 모두 잘 사용하고 다만 사용하는 상황이 서로 다를 뿐이다. form..

모든 개발자를 위한 HTTP 웹 - 3. HTTP 기본 - 비 연결성

-> stateless : 클라이언트와 서버 사이에 상태를 유지하지 않는다. -> connectionless : TCP/IP 커넥션 연결을 지속하지 않는다. Q. Persistence Connections가 언제까지 유지되어야 하는 규칙이 있는가? Psersistence Connections를 비연결성과 연결성의 중간지점이라고 생각해도 되는가? -> 기본적으로 HTTP는 연결을 유지하지 않는 모델로 '비 연결성' 특징이 있다. '비 연결성'은 클라이언트의 요청이 올때마다 3 way handshake를 해야한다는 한계를 갖고 있다. 그래서 불필요하게 많은 3 way handshake 횟수를 줄이기 위해 Persistence Connections라는 것이 나오게 되었다. 한 번 열결이 되면..

모든 개발자를 위한 HTTP 웹 - 3. HTTP 기본 - Stateful, Stateless

1. 상태 유지 - 중간에 다른 점원으로 바뀌면 안된다. (중간에 다른 점원으로 바뀔 때, 상태 정보를 다른 점원에게 미리 알려줘야 한다) 2. 무상태 - 중간에 다른 점원으로 바뀌어도 된다. (갑자기 고객이 증가해도 점원을 대거 투입할 수 있다) -> '무상태'는 응답서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능 '무상태'로 설계할 수 있는 경우도 있고 없는 경우도 있다. 가능한 '무상태'로 설계하고, '상태 유지'는 최소한만 하자. 1. 무상태 - 로그인이 필요없는 단순한 서비스 소개 화면 2. 상태 유지 - 로그인 -> 로그인한 사용자의 경우, 로그인 했다는 상태를 서버에 유지 -> 일반적으로 '브라우저 쿠키'와 '서버 세션'등을 사용해서 상태 유지 Q. 로그인 후 클라이언트가 서버에 ..

모든 개발자를 위한 HTTP 웹 - 2. URI와 웹 브라우저 요청 흐름

웹 브라우저 요청 흐름 정리 웹 브라우저 = 클라이언트, 웹 서버 = 서버 1. 웹 브라우저로 입력된 URL로 부터 IP,PORT 정보를 얻고 웹 브라우저가 HTTP 요청 메세지를 생성한다. 2. 애플리케이션 계층의 '소켓 라이브러리'를 통해 IP, PORT 정보를 '헤더 부분'에 담아 연결을 위한 패킷을 만들고 3-way-handshaking으로 웹 서버와 연결한다 3. 소켓 라이브러리를 통해 HTTP 메세지를 TCP/IP 계층으로 전달한다. 4. 헤더부분(출발지 IP, PORT, 목적지 IP, PORT 등)과 데이터부분(HTTP 요청메세지)을 합쳐 TCP/IP패킷을 생성한다 5. 웹 브라우저에서 인터넷망(수많은 노드들)을 거쳐 '웹 서버'로 패킷을 전달한다. 6. 웹 서버는 도착한 패킷의 헤더 부분은..

모든 개발자를 위한 HTTP 웹 - 1. 인터넷 네트워크 - IP(인터넷 프로토콜)

https://hseungyeon.tistory.com/424?category=1060297 [모든 개발자를 위한 HTTP 웹 기본 지식] 01. 인터넷 네트워크 - 인터넷 통신, IP(인터넷 프로토콜) (인프런) 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 리뷰한 글입니다. 1. 인터넷 통신 1. 인터넷에서 컴퓨터 둘은 어떻게 통신할까? 만약, 클라이언트와 서버가 가까이 있으면 hseungyeon.tistory.com IP(인터넷 프로토콜) 질문 정리 1. 여기서 말하는 클라이언트, 서버의 의미는? -> 요청자 : 클라이언트, 요청 메세지를 받는곳 : 서버 -> 강의에서는 메세지를 보내는 나의 PC에 설치된 애플리케이션 = 클라이언트, 친구의 PC에 설치된 애플리케이션 = 서버 2...