[HTTP] 인터넷 네트워크

 

HTTP 기본 지식

 

IP 인터넷 프로토콜

• 지정한 IP 주소에 데이터(패킷 단위) 전달

TCP(Transmission Control Protocol) 특징

• 연결지향 - TCP 3 way handshake
• 데이터 전달 보증
• 신뢰할 수 있는 프로토콜
• 순서 보장
• 대부분 TCP사용

UDP(User Datagram Protocol)특징

• 연결지향 - TCP 3 way handshake X
• 데이터 전달 보증 X
• 신뢰성 X
• 순서보장 X
• 빠르다.
• ip와 거의 유사 +PORT +checksum 정도만 추가

PORT

• 0~65535 할당 가능
• 0~1023 : 잘 알려진 포트, 사용하지 않는 것이 좋음
  • FTP (File Transfer Protocol) - 20, 21
  • TELNET - 23
    • 리모트(원격) 컴퓨터에 로그온하여 사용할 수 있도록 하는 프로토콜
  • HTTP (Hypertext Transfer Protocol) - 80
  • HTTPS (Hypertext Transfer Protocol Secure) - 443

DNS (Domain Name System)

• 전화번호부
• 도메인 명을 IP 주소로 변경

 

 

URI (Uniform Resource Identifier)

• URI
  • URL(Uniform Resource Locator)
    • scheme : //[userinfo@]host[:port][/path][?query][#fragment]
    • https : https://www.google.com:443/search?q=hello&hl=ko
      • https : 프로토콜
      • www.google.com : 호스트명
      • 443 : port
      • /search : path
      • q=hello&hl=ko : 쿼리파라미터
  • URN(Uniform Resource Name)

 

HTTP (Hypertext Transfer Protocol)

• 거의 모든 데이터의 형태 전송가능 (이미지, Json, 영상, HTML 등등)
• 클라이언트 - 서버 구조
• 무상태(stateless) 프로토콜 , 비연결성(connectionless) → 서버가 클라이언트의 상태 보존X
  • 무상태는 응답 서버를 쉽게 바꿀 수 있다 → 무한한 서버 증설 가능
• 단순하고 확장성이 높음

TCP : HTTP/1.1, HTTP/2

UDP : HTTP/3

현재는 HTTP/1.1 : 가장 많이 사용

 

 

HTTP 메시지

• Start-line (시작라인) : 서버가 수행해야 할 동작 지정
  • 요청
    • 종류: GET, POST, PUT, DELETE…
      • GET : 리소스 조회
      • POST : 요청 내역 처리
  • 응답
    • 상태코드 종류: 200, 400, 500
      • 200 : 성공
      • 400 : 클라이언트 요청 오류
      • 500 : 서버 내부 오류
• Header (헤더)
  • 요청
    • field-name
  • 응답
    • HTTP 전송에 필요한 모든 부가정보

 

HTTP 메서드

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달

ex)

 

POST

• 리소스 생성(등록)
• 요청 데이터 처리
• 메시지 바디를 통해 요청 데이터 처리

ex)

다른 메서드로 처리하기 애매한 경우

ex) JSON으로 조회 데이터를 넘겨야하는데, GET 메서드를 사용하기 어려운 경우

애매하면 POST

 

PUT

• 리소스를 대체
  • 리소스가 있으면 대체(완전히 덮어버림) 없으면 생성
• 클라이언트가 리소스를 식별 → POST와 달리 클라이언트가 구체적으로 지정

ex)

PATCH

• 리소스 부분 변경

ex)

DELETE

• 리소스 제거

ex)

 

HTTP 메서드 속성

• 안전 (Safe Methods)
  • 호출해도 리소스를 변경하지 않는다.
• 멱등 (Idempotent Methods)
  • 한 번 호출하든 여러번 호출하든 결과가 똑같다.
    • GET, PUT, DELETE, POST 중 POST는 멱등이 아니다. ex) 결제 중복 발생가능
• 캐시가능 (Cacheable Methods)
  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
    • 실제로는 GET, HEAD 정도만 캐시로 사용

 

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

• 정적 데이터 조회
  • 쿼리 파라미터 미사용
  • 이미지, 정적 텍스트 문서
  • 조회는 GET 사용
  • 정적 데이터는 보통 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능
• 동적 데이터 조회
  • 쿼리파라미터 사용
  • 검색, 게시판 목록에서 정렬 필터
  • 조회는 GET 사용 (GET은 쿼리 파라미터 사용해서 데이터 전달)
• HTML Form을 통한 데이터 전송
  • POST 전송 - 저장
  • GET 전송 - 조회
• HTTP API를 통한 데이터 전송
  • POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송
  • GET : 조회, 쿼리 파라미터로 데이터 전달
  • application/json을 주로 사용

 

API URI 설계

회원 관리 시스템

• POST 기반 등록 (주로 사용)
• 클라이언트는 등록될 리소스의 URI를 모른다. (서버가 리소스 URI 결정)
• 컬렉션(Collection)
  • 회원 목록 조회 / members → GET
  • 회원 조회 /members/{id} → GET
  • 회원 등록 /members/{id} → POST
  • 회원 수정 /members/{id} → POST, PUT, PATCH
  • 회원 삭제 /members/{id} → DELETE

파일 관리 시스템

• PUT 기반 등록
• 클라이언트가 리소스 URI를 알고 있어야 한다. (클라이언트가 리소스 URI 결정)
• 스토어(Store)
  • 파일 목록 /files → GET
  • 파일 조회 /files/{filename} → GET
  • 파일 등록 /files/{filename} → PUT
  • 파일 삭제 /files/{filename} → DELETE
  • 파일 대량 등록 /files → POST

정리

• 문서 (document)
  • 단일개념 (파일하나, 객체 인스턴스, db row)
  • ex) /members/100 , /files/start.jpg
• 컬렉션
  • 서버가 관리하는 리소스 디렉터리
  • 서버가 리소스의 URI를 생성하고 관리
  • ex) /members
• 스토어
  • 클라이언트가 관리하는 자원 저장소
  • 클라이언트가 리소스의 URI를 알고 관리
  • ex) /files
• 컨트롤러, 컨트롤 URI
  • 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
  • ex) /members/{id}/delete

참고: https://restfulapi.net/resource-naming