📖/spring(김영한)

모든 개발자를 위한 HTTP 웹 기본 지식 2일차

모팔구 2023. 8. 14. 08:17
728x90
반응형

섹션4 HTTP 메서드

HTTP API를 만들어보자

  • 요구사항
    • 회원 목록 조회
    • 회원 조회
    • 회원 등록
    • 회원 수정
    • 회원 삭제
  • URI 설계
    • URI 설계 
      • /read-member-list
      • /read-member-by-id
      • /create-member
      • /update-member
      • /delete-member
      • ⛔️위 uri는 리소스 식별이 전혀 되지 않는다
    • 회원을 등록하고 수정하고 조회하는게 리소스가 아니다 회원이라는 개념 자체가 리소스다
      그럼 리소스를 어떻게 식별하는게 좋을까? 회원에 대한 동작은 모두 배제하고 회원이라는 리소스만 식별하면 된다 즉 회원 리소스를 uri에 매핑시킨다
    • 리소스를 식별해 uri를 설계하면 (참고: 계층 구조상 컬렉션으로 보고 복수단어 사용 권장)
      • 회원 목록 조회 → /members
      • 회원 조회        → /members/{id}
      • 회원 등록        → /members/{id}
      • 회원 수정        → /members/{id}
      • 회원 삭제        → /members/{id}
    • 회원 목록 조회를 제외한 나머지는 어떻게 구별해야 할까? 리소스를 행위를 분리해야 한다 
      • 리소스(명사): 회원
      • 행위(동사): 조회, 등록, 삭제, 변경

HTTP 메서드 - GET, POST

  • HTTP 메서드 종류
    • 주요 메서드 
      • GET: 리소스 조회
      • POST: 요청 데이터 처리, 주로 등록에 사용
      • PUT: 리소스를 대체, 해당 리소스가 없으면 생성
      • PATCH: 리소스 부분 변경
      • DELETE: 리소스 삭제
    • 기타 메서드
      • HEAD, OPTIONS, CONNECT, TRACE
  • GET
    • 리소스 조회
    • 서버에 전다랗고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달함
    • 메시지 바디를 사용해서 데이터를 전달할 수 있지만 지원하지 않는 곳이 많아서 권장하지 않음
  • POST
    • 서버가 아직 식별하지 않은 새 리소스 생성(등록)
    • 요청 데이터 처리
      • 단순히 데이터를 새엇ㅇ하거나 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
      • 주문에서 결제 완료 → 배달 시작 → 배달 완료처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
      • POST의 결과로 새로운 리소스가 생성되지 않을 수 있음
      • 프로세스 처리 uri로 보통 동사 uri(ex. /orders/{orderId}/start-delivery)를 사용한다 이를 컨트롤 uri라고 함
    • 다른 메서드로 처리하기 애매한 경우
      • json으로 조회 데이터를 넘겨야 하는데, GET메서드를 사용하기 어려운 경우
      • 애매하면 POST사용

HTTP 메서드 - PUT, PATCH, DELETE

  • PUT
    • 리소스를 대체하고 해당 리소스가 없으면 생성한다 즉 리소스 덮어쓰기를 한다
    • 클라이언트가 리소스 위치를 알고 URI 지정 ex) PUT /members/100, POST /members
    • json데이터의 일부 키만 지정해 값을 전송하면 지정되지 않은 키와 값들은 그냥 사라짐 
  • PATCH
    • 리소스를 부분 변경한다. PUT의 마지막 항목 단점을 보완한다
    • PUT과 마찬가지로 클라이언트가 리소스의 위치를 알고 URI를 지정한다
    • HTTP가 PATCH 자체를 못 받아들이는 경우가 있는데 이럴 때는 POST를 사용하면 된다
  • DELETE
    • 리소스를 삭제한다
    • 위와 마찬가지로 클라이언트가 리소스의 위치를 알고 URI를 지정한다
  • 위 세가지 모두 POST로 대체 가능해 보인다 .. . .

HTTP 메서드의 속성

  • 안전(Safe Methods): 호출해도 리소스를 변경하지 않으면 안전하다는 의미이다
    • GET, HEAD, OPTIONS, TRACE 해당
  • 멱등(IdemPotent Methods): 한번 호출하던 두번 호출하던 100번 호출하던 결과는 똑같다. 
    • GET, HEAD, PUT, DELETE, OPTIONS, TRACE 해당
    • 멱등의 활용
      • 서버가 TIMEOUT 등으로  정상 응답을 주지 못했을 때 클라이언트가 같은 요청을 다시 하지 해도 괜찮다 
    • 만약 재요청 중간에 다른 곳에서 리소스를 변경해버려도(PUT) 변경된다 멱등은 중간에 리소스가 변경되는 것까지 고려하지는 않는다.
  • 캐시가능(Cacheable Methods)
    • GET, HEAD, POST, PATCH 해당. 실제로는 GET, HEAD 정도만 캐시로 사용함

 

섹션5 HTTP 메서드 활용

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

  • 클라이언트에서 서버로 데이터를 전송하는 방식은 크게 두가지
    • 쿼리 파라미터를 통한 데이터 전송
      • GET
      • 주로 정렬 필터(검색어)
    • 메시지 바디를 통한 데이터 전송
      • POST, PUT, PATCH
      • 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 등
  • 클라이언트에서 서버로 데이터를 전송하는 네가지 상황 
    • 정적 데이터 조회
      • 이미지, 정적 테스트 문서 등을 조회하는 경우를 말하며 메서드는 GET을 사용한다 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능
    • 동적 데이터 조회
      • https://www.google.com/search?q=hello&hl=ko 요게 쿼리 파라미터
      • 주로 검색, 게시판 목록에서 정렬 필터(검색어), 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용하며 메서드는 GET을 사용한다 
    • HTML form태그를 통한 데이터 전송
      • HTML form submit 시 post 전송 ex) 회원 가입, 상품 주문, 데이터 변경
      • Content-Type: application/x-www-form-urlencoded 사용
        • form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)
        • 전송 데이터를 url encoding 처리
      • HTML form은 get 전송도 가능함
      • Content-Type: multipart/form-data
        • 파일 업로드같은 바이너리 데이터 전송 시 사용
        • 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능
      • 참고로 HTML form 태그는 get, post만 지원함
    • HTTP API를 통한 데이터 전송
      • 서버끼리 통신할 때, 앱 클라이언트와 통신할 때, 웹 클라이언트와 통신할 때(AJAX) 등에 사용
      • Content-Type: application/json 주로 사용(사실상 표준) 

HTTP API 설계 예시

  • HTTP API - 컬렉션(POST 기반 등록)
    • 회원 관리 시스템 API 설계
      • 회원 목록 /members        → GET
      • 회원 등록 /members        → POST
      • 회원 조회 /members/{id} → GET
      • 회원 수정 /members/{id} → PATCH, PUT, POST
      • 회원 삭제 /members/{id} → DELETE
    • POST - 신규 자원 등록 특징
      • 클라이언트는 등록될 리소스의 URI를 모른다. 
      • 서버가 새로 등록된 리소스 URI를 새엇ㅇ해준다
      • 컬렉션의 의미
        • 서버가 관리하는 리소스 디렉토리
        • 서버가리 소스의 URI를 생성하고 관리
        • 여기서 컬렉션은 /members
  • HTTP API - 스토어(PUT 기반 등록)
    • 파일 관리 시스템 API 설계
      • 파일 목록 /files                    → GET
      • 파일 조회 /files/{filename} → GET
      • 파일 등록 /files/{filename} → PUT(기존 파일이 있으면 덮어써야 하기 때문)
      • 파일 삭제 /files/{filename} → DELETE
      • 파일 대량 등록 /files            → POST
    • PUT - 신규 자원 등록 특징
      • 클라이언트가 리소스 URI를 알고있어야 한다 
      • 클라이언트가 직접 리소스의 URI를 지정한다
      • 스토어의 의미
        • 클라이언트가 관리하는 리소스 저장소
        • 클라이언트가 리소스의 URI를 알고 관리함
        • 여기서 스토어는 /files
  • HTML FORM 사용
    • HTML form태그는 get, post만 지원하고 ajax 같은 기술을 사용할 수 있음
    • 회원 관리 시스템
      • 회원 목록     /members → GET
      • 회원 등록 폼 /members/new → GET(폼으로 이동하는 url)
      • 회원 등록     /members/new(쌤 선호) || /members → POST(데이터를 전송하는 url)
      • 회원 조회     /members/{id} → GET
      • 회원 수정 폼 /members/{id}/edit → GET(폼으로 이동하는 url)
      • 회원 수정     /members/{id}/edit(쌤 선호) || /members/{id} → POST(데이터를 전송하는 url)
      • 회원 삭제     /members/{id}/delete → POST
    • HTML form 태그는 get, post만 지원하기 때문에 컨트롤 uri를 사용해야 한다는 제약이 있다 즉 POST 메서드 사용 시 동사로 된 리소스 경로를 사용하는 것이다 ex) /new, /edit, /delete 등
  • 참고하면 좋은 URI 설계 개념
    • 문서(document): 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 등)
    • 컬렉션(collection): 서버가 관리하는 리소스 디렉터리. 서버가 리소스의 uri를 생성하고 관리
    • 스토어(store): 클라이언트가 관리하는 자원 저장소. 클라이언트가 리소스의 uri를 알고 관리함
    • 컨트롤러(controller), 컨트롤 URI: 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스를 실행할 때 사용. 동사를 직접 사용함

 

섹션6 HTTP 상태코드

HTTP 상태코드 소개

  • 상태코드: 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
    • 1xx(Informational): 요청이 수신되어 처리 중
    • 2xx(Successful): 요청 정상 처리
    • 3xx(Redirection): 요청을 완료하려면 추가 행동이 필요
    • 4xx(Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
    • 5xx(Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
  • 만약 클라이언트가 인식할 수 없는 상태 코드를 서버가 반환하면 상위 코드로 해석해서 처리하면 된다 ex) 299 -> 2xx 라고 생각

2xx - 성공

  • 200 OK: 요청 성공
  • 201 Created: 요청 성공해서 새로운 리소스가 생성됨. 생성된 리소스는 응답의 Location 헤더 필드로 식별할 수 있음
  • 202 Accepted: 요청이 접수되었으나 처리가 완료되지 않음. 배치 처리 등에서 사용
  • 204 No Content: 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

3xx - 리다이렉션1

  • 리다이렉트: 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 Location 위치로 자동 이동함
  • 리다이렉션의 종류
    • 영구 리다이렉션: 특정 리소스의 uri가 영구적으로 이동함. 그래서 원래 url을 사용하면 안된다 ex) /members → /users
      • 301 Moved Permanently: 리다이렉트 요청 시 메서드가 GET으로 변하고 본문이 제거될 수 있음
      • 308 Permanent Redirect: 301과 기능은 같다. 리다이렉트시 요청 메서드와 본문을 유지한다(처음 POST로 보내면 리다이렉트도 POST가 된다)

3xx - 리다이렉션2

  • 일시 리다이렉션: 일시적인 변경 ex) 주문 완료 후 주문 내역 화면으로 이동 
    • 302 Found(기본): 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음
    • 307 Temporary Redirect(권장): 302와 기능은 같음. 리다이렉트시 요청 메서드와 본문을 유지한다(요청 메서드를 변경하면 안된다)
    • 303 See Other(권장): 302와 기능은 같음. 리다이렉트시 요청 메서드가 GET으로 변경
    •  PRG(Post/Redirect/Get) 패턴
      • POST로 주문 후에 새로고침으로 인한 중복 주문을 방지하기 위한 패턴
      • POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트함
      • 새로고침해도 결과 화면을 GET으로 조회함
  • 특수 리다이렉션: 결과 대신 캐시를 사용
    •  300 Multiple Choices(안씀)
    • 304 Not Modified: 캐시를 목적으로 사용함. 클라이언트에게 리소스가 수정되지 않았음을 알려줌. 따라서 클라이언트는 로컬피씨에 저장된 캐시를 재사용한다(캐시로 리다이렉트함) 304 응답은 로컬 캐시를 사용해야 하므로 응답에 메시지 바디를 포함하면 안된다

4xx - 클라이언트 오류, 5xx - 서버 오류

  • 4xx: 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없음. 즉 오류의 원인이 클라이언트에 있다. 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같은 재시도(새로고침 등)를 해도 실패함
    • 400 Bad Request: 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음. 클라이언트는 요청 내용을 다시 검토하고 보내야함 
    • 401 Unauthorized: 해당 리소스에 대한 클라이언트의 인증이 필요함
      • 인증(Authentication): 본인이 누구인지 확인
      • 인가(Authorization): 권한 부여. 인증이 있어야 인가가 있음
    • 403 Forbidden: 서버가 요청을 이해했지만 승인을 거부함. 주로 인증 자격 증면은 있지만, 접근 권한이 불충분한 경우
    • 404 Not Found: 요청 리소스가 서버에 없어 찾을 수 없음. 
  • 5xx: 서버 문제로 발생한 오류. 서버에 문제가 있기 때문에 재시도하면 성공할 수 있음
    • 500 Internal Server Error: 서버 문제로 오류 발생. 애매하면 보통 500 오류가 발생함
    • 503 Service Unavailable: 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음 

 

 

반응형
728x90
반응형
저작자표시