HTTP

인터넷 네트워크

 

IP 패킷 정보

• 출발지 ip 주소
• 목적지 ip 주소
• 요청, 응답 메시지

IP 프로토콜의 한계

• 비연결성 : 패킷을 받을 대상이 없어도 전송
• 비신뢰성 : 패킷 전달 순서 문제. 패킷 소실
• 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 경우 구분하기가 어렵다.

→ 해결 : TCP. UDP

 

 

TCP

• 전송 제어 프로토콜 :
  • 연결 지향 : 연결되면 보냄 : syn(접속 요청) → syn + ack(요청 수락) → ack + 데이터 전송(데이터 잘 도착했다는 메세지)
  • 전송 순서를 보장
  • 데이터 전달을 보증함

UDP

• IP + PORT + 체크섬 -> 기능이 거의 없다.
• 데이터 전달 순서 보장되지 않지만 단순하고 빠르다. 

→ 클라이언트가 여러 서버 연결

시간 단축 최적화 → 요즘 뜨고 있음

 

패킷 정보

출발지 IP, PORT

목적지 IP, PORT

 

PORT

0~1023 : 잘알려진 포트로 사용하지 않는 것이 좋음

HTTP 기본 포트 80

HTTPS 기본 포트 443 → 대부분 사용

→ 포트 생략 가능

 

DNS(도메인 네임 시스템)

IP가 바뀔 수 있어 사용

DNS 서버에 도메인 명 - ip 등록 (도메인은 사야 함)

~.com으로 ip 주소 변경

 

URI

인터넷의 자원을 식별할 수 있는 문자열을 의미

• URL은 네트워크 상에서 리소스(웹 페이지, 이미지, 동영상 등의 파일) 위치한 정보를 나타낸다.
• URN은 리소스를 어떻게 접근할 것인지 명시하지 않고 경로와 리소스 자체를 특정하는 것을 목표로하는 URI이다.
• 위치는 변할 수 있지만, 이름은 변하지 않는다.
• URI는 URL의 상위 개념

쿼리 파라미터 = 쿼리 스트링 사용

웹 브라우저 요청 흐름

DNS 조회 → IP 주소 알아냄 → HTTP 요청 메시지 생성 → TCP/IP 패킷 안에 넣어 서버에 보내기 → 서버에서 HTTP 응답 메시지 보내줌 → HTML 랜더링

 

HTTP

HTTP/1.1 가장 많이 사용 → TCP 위에서 실행

HTTP/3 요즘 많이 사용 → UDP

클라이언트 Request. 서버 Response 구조

 

무상태(Stateless) 프로토콜

아무 서버나 호출해도 됨 : 응답 서버를 쉽게 바꿀 수 있다. → 무한한 서버 증설 가능 : 스케일 아웃

갑자기 고객이 증가해도 서버를 대거 투입할 수 있다.

선착순 이벤트

 

한계

모든 것을 무상태로 설계 할 수는 없다.

• 상태 유지 : 세션 정보 (로그인)
  • 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
  • 상태 유지는 최소한만 사용
  • 일반적으로 브라우저 쿠키와 서버 세션을 사용
  • 데이터 전송량이 많음

비 연결성

서버 자원을 효율적으로 사용

 

HTTP 메시지

 

시작 라인

요청 메서드

요청 대상

버전

응답 메시지 - 상태 코드

 

HTTP 헤더

모든 부가 정보

 

HTTP 바디

데이터

 

 

API 설계

 

회원 정보 관리

회원 목록 조회 /members

회원 조회 /members/{id}

회원 등록 /members/{id}

회원 수정 /members/{id}

회원 삭제 /members/{id}

 

API URI 설계

• 리소스만 식별해라

리소스 - 회원

• 계층 구조 활용
• /members/{id} 구분

메서드로 행위 분리

 

POST

• 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함
• JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드는 메시지 바디를 잘 허용하지 않음..GET 사용 어려운 경우 → 애매하면 POST 사용
• 리소스로 최대한 URI를 설계 + 어쩔 수 없는 부분은 컨트롤 URI
• → POST/orders/{orderId}/start-delivery

PUT

• 리소스 대체
  • 리소가 있으면 대체, 리소스가 없으면 생성 - 덮어버림
  • 클라이언트가 리소스 위치 알고 URI 지정 - POST와의 차이

{
"username":"old"
}
-> 리소스 대체 
{
"username":"young"
}

 

PATCH

리소스 부분 변경

 

DELETE

리소스 제거

 

HTTP 메서드의 속성

• 안전 : 호출해도 리소스를 변경하지 않는다. GET만 안전
• 멱등 : 한 번 호출하든 계속 호출하든 결과가 똑같다. POST만 아님

POST → 두 번 호출하면 같은 결제가 중복해서 발생

활용 : 자동 복구 메커니즘 : 서버가 Timeout으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청

재요청 중간에 다른 곳에서 리소스를 변경해버리는 것 까지 고려 X : 멱등하지 않다.

get → (post) → get

• 캐시가능

응답 결과 리소스를 캐시해서 사용

POST, PATCH는 캐시 키로 고려해야 하는데 구현이 쉽지 않다.

→ GET, HEAD 정도만 캐시로 사용

클라이언트에서 서버로 데이터 전송

쿼리 파라미터를 통한 데이터 전송

• GET
• 주로 정렬 필터(검색어)

메시지 바디를 통한 데이터 전송

• POST,PUT,PATCH
• 회원가입, 상품 주문, 리소스 등록, 리소스 변경

상황

• 정적 데이터 조회

이미지, 정적 텍스트 문서

조회는 GET 사용

쿼리 파라미터 없이 리소스 경로로 단순 조회 가능

• 동적 데이터 조회

쿼리 파라미터 사용

주로 검색, 게시판 목록에서 정렬 필터(검색어)

조회 조건을 줄여주는 필터, 조회 결과를 정렬 하는 정렬 조건에 주로 사용

조회는 GET

GET은 쿼리 파라미터 사용해서 데이터 전달

• HTML Form 데이터 전송

GET, POST만 사용

→ POST면 바디에 넣고, GET이면 URL 경로로 전송

파일 전송 : multipart/form-data 타입

• HTTP API 데이터 전송
  • 서버 - 서버 통신
  • 앱 클라이언트
  • 웹 클라이언트 : HTML Form 전송 대신 JS를 통한 통신(AJAX) → 프론트와 통신
  • POST, PATCH, PUT : 메시지 바디를 통해 데이터 전송
  • GET : 조회, 쿼리 파라미터로 데이터 전달
  • Content-Type : application/json을 주로 사용

설계 예시

POST 기반 - 컬렉션

• 회원 조회 : 단건 조회
• 회원 수정 : PATCH. POST
• 게시판 게시글 전체 수정 → PUT
• 대부분 POST 기반 등록

파일 관리 시스템 - PUT

• 사용 비율 낮음
• 스토어 기반

• 회원 등록 : members/new
• 회원 수정 : /members/{id}/edit
• 회원 삭제 : POST사용 하기 때문에 URI 경로에 delete 표시
• GET,POST만 지원해서 제약이 있음 → 컨트롤 URI인 동사 리소스 경로 사용해야 함
• 컨트롤 URI : /delete, /edit, /new

→ HTTP API 포함

 

URI 설계 개념

https://restfulapi.net/resource-naming