HTTP 메서드와 활용

📒 좋은 URI 설계는 뭘까?

📌 리소스 식별

가장 중요한 것은 리소스 식별. 회원 정보 관리 API를 만들어보자.

필요한 기능이 뭐가 있더라...

회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제?

📝리소스란?

"회원"이라는 개념 자체가 바로 리소스!

📝리소스를 어떻게 식별하나?

회원을 등록, 수정, 삭제하는 것은 생각하지 말고 회원 자체만 리소스로 식별해서 회원 리소스를 URI에 매핑

📌리소스와 행위 분리

* URI는 리소스만 식별!

* 리소스와 해당 리소스를 대상으로 하는 행위를 분리해야 함.

예시로 들었던 회원 정보 관리 API의 경우 리소스는 회원이고 행위는 조회, 등록, 삭제, 변경이다.

즉 리소스는 명사, 행위는 동사

그럼 행위(메서드)는 어떻게 구분하지? 그래서 등장하는 것이 ★HTTP 메서드★

📒 HTTP 메서드

📌 GET: 리소스 조회

* 서버에 전달하고 싶은 데이터는 query를 통해 전달

📌 POST: 요청 데이터 처리, 주로 등록에 사용

* 메세지 바디를 통해 서버로 요청 데이터 처리 해달라고 전달

* 요청 데이터를 처리. 메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능 수행

* 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리(단순히 데이터 생성이나 변경을 넘어 프로세스의 상태가 변경되는 경우)에 사용.

단, POST의 결과로 새로운 리소스가 생성되지 않을 수 있음. URI에 동사가 포함될 수 있음. (:컨트롤 URI 예를 들어 배달 시작의 경우 POST/orders/{orderId}/start-delivery)

-> 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함 (정해진 것이 없음)

-> 다른 메서드로 처리하기 애매하면 POST

📌 PUT: 리소스를 대체, 해당 리소스가 없으면 생성. 있으면 덮어쓰기

* 폴더에 파일 복사하는 로직과 같음.

* 리소스가 이미 있으면 완전히 대체, 없으면 생성

* !주의! 기존 내용을 완전히 갈아치우는 것. 리소스를 부분적으로 수정하기 어려움. -> PATCH

* POST와의 차이점: 클라이언트가 리소스를 식별. POST는 리소스를 생성은 하지만 몇번에 넣는지 위치는 모름. 하지만 PUT은 정확히 100번에 집어넣을거야!라고 클라이언트가 리소스를 알고 URI 지정.

📌 PATCH: 리소스 부분 변경

* 리소스가 이미 있는 경우 내가 수정하고 싶은 리소스만 PATCH로 보내주면 됨.

* PATCH가 지원이 안되는 서버가 있을 수 있음. (거의 대부분 될테지만)

📌 DELETE: 리소스 삭제

* 리소스 삭제

📒 HTTP 메서드의 속성

📌 안전 (Safe Methods)

* 호출해도 리소스를 변경하지 않음. 로그가 쌓이고 어쩌구 하는 부분은 고려하지 않음.

📌멱등(Idempotent Methods)

* f(f(x))=f(x)

* 한 번 호출하든 두 번 호출하든 오만번 호출하든 결과가 똑같음.

* 멱등 메서드: GET, PUT, DELETE (POST는 멱등아님! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있음.)

* 재요청 중간에 사용자가 바뀌어서 리소스를 변경하는 등 외부 요인으로 인해 중간에 리소스가 변경되는 것은 고려하지 않음.

📌캐시 가능(Cacheable Medthods)

* 응답 결과 리소스를 캐시해서 사용해도 되는가?

* 캐시 가능 메서드: GET, HEAD, POST, PATCH

* 실제로는 GET만 캐시로 사용

📒 HTTP 메서드 활용

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

데이터 전달 방식은 크게 2가지인데,

📝 쿼리 파라미터(쿼리 스트링)를 통한 데이터 전송

* 참고로 쿼리 파라미터란 key-value 형태로 이루어져서 '?'로 시작하는 '?q=hello&hl=ko'같은것

* GET 메서드에서 주로 사용

* 주로 정렬 필터 (=검색어)

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

* POST, PUT, PATCH 메서드에서 주로 사용

* 회원 가입, 상품 주문, 리소스 등록, 리소스 변경

📝 정적 데이터 조회

* 이미지, 정적 텍스트 문서 등의 조회는 GET 사용

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

📝 동적 데이터 조회

* 쿼리 파라미터를 기반으로 key-value값을 이용해 정렬 필터해서 결과를 동적으로 생성

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

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

* 조회는 GET 사용, 쿼리 파라미터를 사용해 데이터 전달

📝 HTML Form을 통한 데이터 전송

* 이런 HTML Form에서 submit하면

웹 브라우저가 아래와 같은 HTTP 메세지를 생성해서 body에 넣어줌.

* Content-Type: application/x-www-form-urlencoded 사용

* 폼의 내용을 메세지 바디를 통해 전송(key=value, 쿼리 파라미터 형식)

* 전송 데이터를 url encoding 처리 (예를 들어, abc김 -> abc%EA%B9%80)

* GET 메서드도 가능함. (단, 조회에만 사용! 리소스 변경이 발생하는 곳에 사용하면 안됨.)

* GET이면 웹 브라우저가 URL경로로 쿼리를 넣어주고, POST면 메세지 body에 넣어줌.

* 파일 업로드같은 바이너리 데이터를 전송할 때나 다른 종류의 여러 파일과 폼의 내용을 함께 전송할 때는 enctype="multipart/form-data"

* 회원 가입, 상품 주문, 데이터 변경

📝 HTTP API를 통한 데이터 전송

* HTML Form을 사용하지 않는, 직접 손수 API를 넘기는 방법. Content-Type은 json으로.