김영한 님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 정리한 내용입니다.
클라이언트 - 서버 구조
클라이언트는 서버에 요청을 보내고 서버 응답이 올 때까지 기다린다.
이렇게 분리 되어 있어서 좋은 점은? 클라이언트와 서버가 각자 독립적으로 진화할 수 있다.
- 클라이언트는 복잡한 비즈니스 로직, 데이터를 다루지 않고 UI/UX에 집중할 수 있다.
- 서버는 UI/UX에 대해 몰라도 되고 데이터나 비즈니스 로직에만 집중할 수 있다.
Stateless vs Stateful
- Stateful 예시
고객: 노트북 얼마에요?
점원A: 100만원이요
고객: 2개 주세요.
점원A: 200만원입니다. 현금, 신용카드 중 어떤 걸로 계산하시겠어요?
고객: 신용카드로 결제해 주세요.
점원A: 신용카드로 200만원 결제 완료되었습니다.
- Stateless 예시
고객: 노트북 얼마에요?
점원A: 100만원이요
고객: 2개 주세요.
점원B: ?? 어떤 거 2개 말씀이신가요?
고객: 신용카드로 결제해 주세요.
점원A: ?? 어떤 걸요?
Stateful
Stateful에서는 컨텍스트(맥락)을 알아야 응답이 가능하다. 그래서 중간에 다른 점원으로 바뀌면 안 된다. 바꾸려면 다른 점원에게 정보를 미리 알려줘야 된다.
고객: 노트북 얼마에요?
점원A: 100만원이에요
(점원 B에게 A가 노트북 얼마냐고 물어봤다는 사실을 전한다)
고객: 2개 주세요.
점원B: 200만원입니다. 현금, 신용카드 중 어떤 걸로 계산하시겠어요?
이렇게 해야만 다른 점원(서버)에게 요청했을 때도 응답이 가능하다.
Stateless
상태 유지가 되지 않는 상황에서 고객(클라이언트)은 이렇게 요청해야 한다.
고객: 노트북 2개 신용카드로 결제해 주세요.
점원A: 신용카드로 200만원 결제 완료되었습니다.
그러면 어떤 점원에게 가든 제대로 결제할 수 있다.
고객: 노트북 2개 신용카드로 결제해 주세요.
점원B: 신용카드로 200만원 결제 완료되었습니다.
고객: 노트북 2개 신용카드로 결제해 주세요.
점원C: 신용카드로 200만원 결제 완료되었습니다.
어떤 점원에게든 결제가 가능하기 때문에 확장성이 좋다.
예를 들어, A 서버로 요청을 보냈는데 A 서버에 장애가 발생하면 B 서버로 보내면 응답을 받을 수 있다. 갑자기 클라이언트 요청이 증가하면 서버를 증설해서 대거 투입할 수 있다.
단점: 많은 정보를 보내야 된다(노트북 2개 신용카드로 결제해 주세요.)
HTTP 메서드
URI 이름 짓는 방법?
리소스(미네랄을 캔다고 하면 '캔다'는 행위가 아니라 '미네랄'이 리소스다)를 기준으로 이름을 짓는다.
근데 그렇게 되면
회원 목록: members
회원 조회: members/{id}
회원 생성: members/{id}
회원 삭제: members/{id
}.............?? 조회/생성/삭제 구분 어떻게 하지??
바로 HTTP 메서드로 구분한다!
행위는 HTTP 메서드로 구분한다
HTTP 메서드
- GET: 조회
- PUT
리소스가 있으면 완전히 대체(덮어 버림), 없으면 생성
클라이언트가 리소스 위치를 알고 URI 지정한다! (이게 POST와의 차이점이다) - PATCH
리소스 부분 변경! - DELETE: 삭제
HTTP 메서드의 특성
1. 안전
호출해도 리소스를 변경하지 않는 속성
- GET, HEAD: 안전
- 나머지는 리소스를 바꾸는 메소드니까 안전하지 않다.
2. 멱등(idempotent)
같은 메소드를 한 번 호출하든 여러 번 호출하든 같은 결과가 나오는가? 그럼 '멱등하다'라고 한다.
멱등: 같은 메서드를 1번 호출하나 100번 호출하나 결과가 같은 것
- GET / PUT / DELETE: 여러 번 요청해도 결과는 같다. 계속 조회해도 결과는 같고, PUT은 리소스를 덮어버리니까 계속 같은 결과가 나오고, DELETE을 여러 번 해도 결과는 항상 '삭제된 상태'기 때문에 같다.
- POST: 멱등 X. 결제를 여러 번 하면 그 결과는 같지 않다.
이걸 왜 알아야 할까? 💡 서버가 타임아웃 등으로 정상 응답을 못 주었을 때 클라이언트가 재요청을 해야 하는지 판단하기 위해
(결제 요청 후 정상 응답이 안 와서 결제가 됐는지 안 됐는지 모를 때는 재요청 하면 안 된다. 결제가 여러 번 될 수도 있으니까)
3. 캐시 가능(cacheable)
캐시란?
💡 크기가 큰 리소스를 요청해서 응답을 받았을 때, 웹 브라우저가 그 리소스를 내 로컬 PC에 저장하는 것.
그래서 다음에 그 리소스가 필요할 때는 또 요청할 필요 없이 내 로컬 PC에서 가져와서 사용할 수 있다.
실제로는 GET이랑 HEAD 정도만 캐시로 사용 가능하다.
클라이언트에서 서버로 데이터 전송
동적 데이터 조회
- GET 메소드, 쿼리 파라미터 사용
- 조회 조건을 줄여주는 필터나 조회 결과를 보여주는 정렬 조건에서 주로 사용
HTML Form 데이터 전송
form 태그 안의 전송 버튼을 누르면 웹 브라우저가 form의 데이터를 읽어서 HTTP 메시지를 생성해 준다.
- GET, POST만 지원
HTTP API 데이터 전송
