HTTP 메소드

put

- 리소스가 있으면 대체
- 리소스가 없으면 생성
- 쉽게 이야기해서 덮어버림

## 완전히 대체해버림

중요! 클라이언트가 리소스를 식별

ㅡ클라이언트가 리소스 위치를 알고 URI 지정
  - 리소스의 위치가 POST에비해 확실히 지정함 
(POST가 /members 에 보낸다면,
 PUT은 /members/100에 보낸다.)

--POST와 차이점


----

HTTP 메서드의 속성

# 안전(Safe method)

- 호출해도 리소스를 변경하지 않는다.
- Q:그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면요?
- A:안전은 해당 리소스만 고려한다. 그런부분은 고려하지 않는다.

# 멱등(Idempotent)

- f(f(x)) = f(x)
- 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
- 멱등 메서드
-GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
-POST : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
-DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
-POST : 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

- 활용
-자동 복구 메커니즘
- 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가? 판단 근거

- Q : 재쵸정 중간에 다른 곳에서 리소스를 변경해버리면?
- 사용자1: GET -> username:A, age:20
- 사용자2: PUT -> username:A, age:30
- 사용자1: GET -> username:A, age:30 -> 사용자2의 영향으로 바뀐 데이터 조회된다
- A : 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.


캐시가능 (Cacheable)

-응답 결과 리소스를 캐시해서 사용해도 되는가?
-GET,HEAD,POST,PATCH 캐시가능
-실제로는 GET,HEAD 정도만 캐시로 사용
-POST,PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음


------------------------------------------------------------------------------------

#HTTP 메서드 활용

-클라이언트에서 서버로 데이터 전송
-HTTP API 설계 예시

클라이언트에서 서버로 데이터 전송
(데이터 전달 방식은 크게 2가지)

- 퀄리 파라미터를 통합 데이터 전송
-GET
-주로 정렬 필터(검색어)

- 메시지 바디를 통한 데이터 전송
-POST, PUT, PATCH
-회원 가입, 상품 주문,리소스 등록, 리소스변경

#클라이언트에서 서버로 데이터 전송
(4가지 상황)

- 정적 데이터 조회
-이미지, 정적 텍스트 문서
(간단하게 이미지들이랄까 파일 같은거 불러올 때)

- 동적 데이터 조회된다
-주로 검색, 게시판 목록에서 정렬 필터(검색어)
(파라미터 값 같은 쿼리파라미터 값이 들어가서 바뀌는 데이터를 조회할 때)
(조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용)
(조회는 GET 사용)
(GET은 쿼리 파라미터 사용해서 데이터 전달)

-HTML Form을 통한 데이터 전송
-회원 가입, 상품 주문, 데이터 변경
(POST 전송 - 저장)
(GET 전송은 조회에만 사용해야함 리소스 변경이 발생하는 곳에 사용하면 안됨!)
-Content-Type: application/x-www-form-urlencoded
-form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리파라미터 형식)
-전송 데이터를 url enconding처리
+예)abc김 -> abc%EA%B9%80

-HTML Form은 GET 전송도 가능
-Content-Type:multiaprt/form-data
-파일 업로드 같은 바이너리 데이터 전송시 사용자1
-다른 종류의 여러 파일과 폼의 내용 함께 전송 가능(그래서 이름이 multipart)
-참고: HTML Form 전송은 GET,POST만 지원

-HTTP API를 통한 데이터 전송
-회원 가입, 상품 주문, 데이터 변경되는
-서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)
-앱 클라이언트
-아이폰, 안드로이드
-웹 클라이언트
-HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용(AJAX)
-예)REACT,VueJS같은 웹 클아이언트와 API 통신
-POST, PUT, PATCH:메시지 바디를 통해 데이터 전송
-GET:조회, 쿼리 파라미터로 데이터 전달
-Content-Type:application/json을 주로 사용(사실상표준)
-TEXT,XML,JSON 등등

--------------------------------------------------------------

HTTP API 설계 예시
- HTTP API - 컬렉션
-POST 기반 등록
-예) 회원 관리 API 제공
- HTTP API - 스토어
-PUT 기반 등록
-예) 정적 컨텐츠 관리, 원격 파일 관리
- HTTP FORM 사용
-웹 페이지 회원 관리
-GET,POST만 지원

회원 관리 시스템
API 설계 - POST 기반 등록
- 회원 목록 /members -> GET
- 회원 등록 /members -> POST
- 회원 조회 /members/{id} -> GET
- 회원 수정 /members/{id} -> PATCH, PUT, POST
- 회원 삭제 /members/{id} -> DELETE

-클라이언트는 등록될 리소스의 URI를 모른다.
- 회원 등록 /members -> POST
- POST /members

-서버가 새로 등록된 리소스 URI를 생성해준다.
-HTTP/1.1 201 Created
 Location: /members/100

-컬렉션(Collection)
-서버가 관리하는 리소스 디렉토리
-서버가 리소스의 URI를 생성하고 관리
-여기서 컬렉션은 /members


파일 관리 시스템
API 설계 - PUT 기반 등록
-파일 목록/files-> GET
-파일 조회 /files/{filename} -> GET
-파일 등록 /files/{filename} -> PUT
-파일 삭제 /files/{filename} -> DELETE
-파일 대량 등록 /files -> POST