HTTP 기본과 메서드

챠밍·2022년 3월 17일
0

HTTP 웹 기본 지식

목록 보기
2/4
post-thumbnail

< HTTP 특징 >

  1. 거의 모든 형태의 데이터 전송 가능
  2. 클라이언트 서버 구조
  3. 무상태 프로토콜, 비 연결성
  4. 단순하고 확장 가능하다
  • 클라이언트 서버 구조

    클라이언트가 서버에 요청을 보내고 서버가 결과를 응답

  • 무상태 프로토콜(Stateless)

    1. 서버가 클라이언트 상태를 보존하지 않는 것,
    2. 서버가 바뀌어도 요청을 처리할 수 있다
      단, 요청하는 데이터 양이 많다는 단점이 있다.
      exc) 로그인 같은 서비스는 상태유지로 처리
  • 비연결성

    요청을 받고 응답을 보내는 동시에 연결을 끊음
    --> 서버 자원 최소한 유지

    • 한계점 해결 : 지속 연결을 통해 속도 개선
  • HTTP 메세지

시작라인 : 요청-메서드 / 응답-상태코드
헤더 : 전송에 필요한 모든 부가 정보
공백라인
body: 실제 전송 데아터 (html, image, 영상, json 등..)


< HTTP 메서드 >

URI 설계는 리소스 식별을 기준으로 설계하자!

* 리소스와 행위를 분리하자 !

리소스 : 멤버
행위 : 등록 / 수정 / 삭제 / 조회

  • HTTP 메서드

  1. GET : 쿼리를 통해 서버로 요청 데이터 전달 / 리소스 조회
  2. POST : 메시지 바디를 통해 서버로 요청 데이터 전달 / 요청 데이터 처리
    ** 애매하면 POST 사용 !
  3. PUT : 리소스가 있으면 대체, 없으면 생성
    클라이언트가 리소스를 식별 (post와 차이점)
  4. PATCH : 리소스 부분 변경 (PUT과 차이점)
  5. DELETE : 리소스 제거
  • 속성

    1. 안전 : 호출해도 리소스를 변경하지 않는다.
      ex) GET, HEAD
    2. 멱등 : 동일한 호출을 100번 해도 결과는 똑같다.
      ex) GET, PUT, DELETE
      ** POST는 멱등이 아님! (두 번 결제하면 중복 결제!)
    3. 캐시가능 : 응답 결과 리소스를 캐시해둠
      ex) GET, HEAD 정도만 사용,,

< HTTP 메서드 활용 >

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

  1. 쿼리 파라미터를 통한 데이터 전송
  • GET
  • 정렬 필터 (검색어)
  1. 메시지 바디를 통한 데이터 전송
  • POST, PUT, PATCH
  • 회원가입, 상품주문, 리소스 등록, 리소스 수정

HTTP API 설계 (주로 JSON)

  • post : 클라이언트가 리소스 URI를 모름, 서버가 알아서 결정
    ** post 기반의 등록 : 컬렉션
  • put : 클라이언트가 리소스 URI를 알고있어야한다. 클라이언트가 직접 지정
    ** put 기반의 등록 : 스토어

HTML FORM 사용

  • <GET, POST> 만 사용 가능
  • 조회하거나 폼 자체를 보는것은 GET 사용
  • 나머지는 리소스 경로로 표현해주고(=컨트롤 URI) POST 사용

정리 !

  1. 문서(document)
    단일 개념 (파일 하나, 객체 인스턴스, 데이터베이스 row)
    예) /members/100, /files/star.jpg
  2. 컬렉션(collection)
    서버가 관리하는 리소스 디렉터리
    서버가 리소스의 URI를 생성하고 관리
    예) /members
  3. 스토어(store)
    클라이언트가 관리하는 자원 저장소
    클라이언트가 리소스의 URI를 알고 관리
    예) /files
  4. 컨트롤러(controller), 컨트롤 URI
    문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
    동사를 직접 사용
    예) /members/{id}/delete
profile
SW developer

0개의 댓글