WEB CS 기초 - section 4 HTTP 메서드(2)

* 해당 글은 멋사 부트캠프 CS 기초 추가강의 내용 정리글입니다.

https://bootcamp.likelion.net/school/kdt-backendj-21th

백엔드 부트캠프 21기: Java : 멋사 부트캠프

 

 

HTTP 메서드의 속성

• 안전(Safe Methods)
• 캐시 가능(Cacheable Methods)
• 멱등(Idempotent Methods)

* 멱등(Idempotent Methods)

- f(f(x)) = f(x)

- 한 번 호출하든, 두 번 호출하든 100번 호출하든 결과가 똑같다.

- 멱등 메소드는 다음과 같다.

- GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 나온다.

- PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.

- DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.

- POST : 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

 

* 멱등의 활용?

- 자동 복구 메커니즘에서 활용 가능한 속성이다.

- 서버가 timeout 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가에 대한 판단 근거가 된다.

 

그렇다면 아래와 같은 경우는 어떨까?

- 재요청 중간에 다른 곳에서 리소스를 변경해버리면 어떻게 될까?

- 사용자1 : GET -> username:A, age:20

- 사용자2 : POST -> username:A, age:30

- 사용자3 : GET -> username:A, age30 -> 사용자2의 영향으로 바뀐 데이터 조회

- 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.

 

* 캐시 가능(Cacheable Methos)

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

- GET, HEAD, POST, PATCH : 캐시 가능

- 실제로는 GET, HEAD 정도만 캐시로 사용한다.

- POST, PATCH 는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다.

 

HTTP 메소드 활용

클라이언트에서 서버로 데이터를 전송할 때 HTTP API 를 어떻게 설계하는지 예시를 알아보자.

 

* 클라이언트 에서 서버로 데이터를 전송하는 경우

데이터 전달 방식은 크게 2가지가 있다.

- 쿼리 파라미터를 통한 데이터 전송

- 메시지 바디를 통한 데이터 전송

여기서 쿼리 파라미터를 통해 데이터를 전송하는 경우는 GET 메소드를 활용하거나, 정렬, 필터(검색어) 기능을 구현할 때가 해당된다.

메시지 바디를 통해 데이터를 전송하는 경우는 POST, PUT, PATCH 등의 메소드를 활용하거나, 회원 가입, 상품 주문, 리소스 등록, 리소스 변경과 같은 기능을 구현할 때가 해당된다.

 

클라이언트에서 서버로 데이터를 전송하는 구체적인 4가지 상황

- 정적 데이터 조회 : 이미지, 정적 텍스트 문서

- 동적 데이터 조회 : 주로 검색, 게시판 목록에서 정렬, 필터(검색어) 기능 구현 시

- HTML FORM 을 통한 데이터 전송 : 회원 가입, 상품 주문, 데이터 변경

- HTTP API 를 통한 데이터 전송 : 

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

    - 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax) 간 데이터 전송

 

* 정적 데이터 조회

쿼리 파라미터를 사용하지 않는 경우 추가 데이터를 전달할 필요가 없다. 경로만 정확하게 전달해주면 정적 데이터를 조회할 수 있다.

- 이미지, 정적 텍스트 문서를 조회하는 경우 정적 데이터 조회에 해당한다.

- 메소드로는 GET 을 사용한다.

- 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회가 가능하다.

 

* 동적 데이터 조회

쿼리 파라미터를 사용하는 경우에 해당한다.

- 주로 검색, 게시판 목록에서 정렬 또는 필터(검색어) 를 활용할 때에 해당한다.

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

- 메소드로는 GET 을 사용한다.

- 이때 GET 은 쿼리 파라미터를 사용해서 데이터를 전달한다.

 

* HTML FORM 데이터 전송

- HTML Form submit 시 POST 메소드로 전송한다.

예시 : 회원 가입, 상품 주문, 데이터 변경 등

- Content-Type 이 application/x-www-form-urlencoded 인 경우

    - form 의 내용을 메시지 바디를 통해서 전송한다.(key=value, 쿼리 파라미터 형식)

    - 전송 데이터를 url encoding 처리한다. (예시 : abc김 -> abc%EA%B9%80 - 퍼센트 인코딩)

- HTML Form 은 GET 전송도 가능하다. 이때 form 의 내용은 메시지 바디가 아니라 쿼리 파라미터 형식으로 넘어간다.

(단, 이때 리소스의 변경이 발생해서는 안된다. GET 은 리소스 조회의 경우에만 사용한다.)

- Content-Type 이 multipart/form-data 인 경우

    - 파일 업로드 같은 바이너리 데이터 전송 시 사용한다.

    - 다른 종류의 여러 파일과 폼의 내용을 함께 전송 가능하다.

+ 참고 : HTML Form 전송은 GET, POST 만 지원한다.

 

* HTTP API 를 통해 데이터를 전송할 경우

- 서버 to 서버와 같이 백엔드 시스템 끼리 통신할 때 사용한다.

- 앱 클라이언트 : 아이폰, 안드로이드와 같은 앱 클라이언트 간에 데이터를 전송할 때도 HTTP API 를 많이 활용한다.

- 웹 클라이언트 : 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 기반 리소스 등록, 예시 : 정적 컨텐츠 관리, 원격 파일 관리

HTML FORM 사용 : 웹 페이지 회원 관리에 활용, GET, POST 만 지원한다.

 

* 회원관리 시스템

API 설계 - POST 기반 리소스 등록

URI 는 리소스를 식별해야지, 다른걸 식별해서는 안된다.

각종 API 를 POST 를 기반으로 다음과 같이 설계한다고 해보자.

- 회원 목록 : /members -> GET

- 회원 등록 : /members -> POST

- 회원 조회 : /members/{id} -> GET

- 회원 수정 : /members/{id} -> PATCH (정보의 수정 시 PATCH 를 쓰는것이 좋다), PUT, POST

- 회원 삭제 : /members/{id} -> DELETE

 

- 클라이언트는 등록될 리소스의 URI 를 모른다.

회원 등록의 경우 클라이언트에서 서버로 전송되는 URI : POST /members

- POST 로 리소스를 등록할 때는 서버에서 해당 리소스를 등록해준 후 URI 를 만들어준다.

리소스가 서버에 의해 등록된 이후 서버에서 생성한 리소스 URI : HTTP/1.1 201 Created Location : /members/100

- 컬렉션(Collection)

    - 서버가 관리하는 리소스 디렉토리

    - 서버가 리소스의 URI 를 생성하고 관리한다.

    - 여기서 컬렉션은 /members 이다.

 

API 설계 - PUT 기반 등록

각종 API 를 PUT 을 기반으로 다음과 같이 설계한다고 가정하자.

- 파일 목록 : /files -> GET

- 파일 조회 : /files/{filename} -> GET

- 파일 등록 : /files/{filename} -> PUT

- 파일 삭제 : /files/{filename} -> DELETE

- 파일 대량 등록 : /files -> POST

 

- 클라이언트가 리소스 URI 를 알고 있어야 한다.

파일 등록 /files/{filename} -> PUT (PUT /files/star.jpg)

- 클라이언트가 직접 리소스의 URI 를 지정한다.

- 스토어(Store)

    - 클라이언트가 관리하는 리소스 저장소

    - 클라이언트가 리소스의 URI 를 알고 관리한다.

    - 여기서 스토어는 /files

 

+ 참고 : 보통은 대부분 POST 기반의 신규 자원등록 방식을 사용한다.

 

* HTML FORM 사용

- HTML FORM 은 GET, POST 만 지원한다.

- AJAX 같은 기술을 사용해서 위와 같은 문제를 해결 가능하다.

- 여기서는 순수 HTML FORM 을 가지고 문제를 해결한다고 가정하자.

- GET, POST 만 지원하므로 제약이 있다.

 

HTML FORM 을 기반으로 한 API 설계

- 회원 목록 : /members -> GET

- 회원 등록 폼 : /members/new -> GET

- 회원 등록 : /members/new, /members -> POST

- 회원 조회 : /members/{id} -> GET

- 회원 수정 폼 : /members/{id}/edit -> GET

- 회원 수정 : /members/{id}/edit, /members/{id} -> POST

- 회원 삭제 : /members/{id}/delete -> POST 

 

HTML FORM 은 GET, POST 만 지원하기 때문에 다른 메소드를 사용하는데 제약이 있다.

이를 극복하기 위해 컨트롤 URI 를 사용해야 한다.

- GET, POST 만 지원하므로 제약이 있다.

- 이런 제약을 해결하기 위해 동사로 된 리소스 경로를 사용한다.

- POST 의 /new, /edit, /delete 가 컨트롤 URI 이다.

- HTTP 메소드로 해결하기 애매한 경우 사용한다. (HTTP API 포함)

 

* 정리

참고하면 좋은 URI 설계 개념

- 문서(document)

    - 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)

    - 예시 : /members/100, /files/star.jpg

- 컬렉션(collection)

    - 서버가 관리하는 리소스 디렉터리

    - 서버가 리소스의 URI 를 생성하고 관리한다.

    - 예시 : /members

- 스토어(store)

    - 클라이언트가 관리하는 자원 저장소

    - 클라이언트가 리소스의 URI 를 알고 관리한다.

    - 예시 : /files

- 컨트롤러(controller), 컨트롤 URI

    - 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행

    - 동사를 직접 사용한다.

    - 예시 : /members/{id}/delete

 

기준은 컬렉션과 스토어 형태를 가지고 API 를 설계하되, 그 둘로도 해결이 안되면 컨트롤 URI 를 활용한다.