HTTP) HTTP 메서드의 활용, HTTP API설계, 컬렉션, 스토어, HTTP FORM

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

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

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

정적 데이터 조회	이미지, 정적 테스트 문서
동적 데이터 조회	주로 검색이나 게시판 목록에서 정렬
HTML FORM을 통한 데이터 전송시	회원가입, 상품주문, 데이터 변경
HTTP API를 통한 데이터 전송	회원가입, 상품주문, 데이터 변경  서버 to 서버, 앱 클라이언트, 웹 클라이언트

정적 데이터 조회

: URI경로를 조회하면 데이터 넘겨줌 - 쿼리 파라미터 없이 리소스 경로로 단순히 조회 가능.

동적 데이터 조회

: GET은 쿼리 파라미너를 사용해 데이터를 전달하고

: 쿼리 파라미터를 key=value로 꺼내어 조회 결과를 응답함.

HTML FORM을 통한 데이터 전송시

POST 전송-저장

: 쿼리 파라미터와 유사한 key=value형식으로 HTTP 메세지 바디에 넣어 전송함.

: 서버에서 받은 데이터를 저장.

GET 전송-저장

: GET으로 전송시 HTTP메세지 바디를 사용하지 않아서 URI 쿼리 파라미터에 값을 넣어서 전달함.

* GET은 당연히 조회로만 사용해야함.

multipart/form-data

: 파일 업로드 같은 바이너리 데이터 전송 시 enctype="multipart/form-data"를 사용함.

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

 

* HTML Form전송은 GET, POST만 지원된다.

HTTP API를 통한 데이터 전송

: 서버 to 서버 - 백엔드 시스템 통신이다.

: 앱 클라이언트 - 아이폰, 안드로이드에서 많이 사용한다.

: 웹 클라이언트

- HTML 에서 Form전송 대신 자바 스크립트를 통한 AJAX통신에 사용된다.

- 예) React, Vue.js같은 웹 클라이언트와 AIP통신

: POST, PUT, PATCH일 때 메시지 바디를 통해 데이터 전송 가능.

: GET - 조회, 쿼리 파라미터로 데이터 전송.

---

HTTP API설계

-HTTP API - 컬렉션 (POST 기반 등록)

-HTTP API - 스토어 (PUT 기반 등록)

-HTTP FORM 사용 (GET, POST만 지원)

---

HTTP API - 컬렉션 (POST 기반 등록)

요구사항	URI설계	더 좋은 URI설계	구분하는 방법
회원 목록	/read-member-list	/members	GET
회원 등록	/create-member	/members	POST
회원 조회	/read-member-by-id	/members/{id}	GET
회원 수정	/update-member	/members/{id}	PATCH, PUT, POST
회원 삭제	/delete-member	/members/{id}	DELETE

: 컬렉션에 데이터를 넣으면 목록, 등록, 조회, 수정, 삭제의 행위가 일어남.

: 수정에서는 PATCH가 개념적으로 가장 좋지만 PUT, POST를 쓸 수도 있다.

 

POST 기반 등록 특징

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

: 서버에서 식별할 수 있는 리소스의 URI를 만들어준다.

HTTP/1.1 201 Created
Location:/members/100

: 컬렉션(Collection)

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

- 서버가 생성하고 관리하는 리소스의 URI

-> 이런것들을 컬렉션이라고 한다. (예시에서는 /members가 컬렉션!)

HTTP API - 스토어 (PUT 기반 등록)

파일 관리 - API 설계

요구사항	URI설계	구분
파일 목록	/files	GET
파일 조회	/files/{filename}	GET
파일 등록	/files/{filename}	PUT
파일 삭제	/files/{filename}	DELETE
파일 대량 등록	/files	POST

: 등록시 파일명은 클라이언트가 알고있음.

: PUT을 사용 시 없으면 생성, 있으면 모두 덮어버림

: 필요없는 파일은 없어도 됨으로 PUT이 어울릴 수 있음.

PUT 기반 등록 특징

: 클라이언트가 직접 리소스 URI를 알고 있어야 한다. ( PUT /files/myfile.jpg )

: POST가 서버에 요청을 하는 모양이라면 PUT은 클라이언트가 아는것을 서버에 알려주고 서버는 처리하는 모양이다.

: 스토어(Store)

- 클라이언트가 관리하는 리소스의 저장소이고 이 리소스 URI는 클라이언트가 알고 직접 관리한다.

-> 이런것을 스토어라고 한다. (예시에서는 /files가 스토어!)

 

 

***대부분 POST방식을 사용하고 PUT은 잘 안쓴다.

HTTP FORM 사용 (GET, POST만 지원)

*SCRIPT나 AJAX같은 기술을 사용해서 API통신이 가능하기는 하다.

순수 HTML FORM은 GET과 POST만 지원함으로 제약이 있다.

요구사항	URI설계	구분
회원 목록	/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

* GET, POST만 지원하므로 제약을 해결하기 위해 동사로 된 /new, /edit, /delete와 같은 리소스 경로를 사용한다.

---

참고하면 좋은 URI설계 개념

https://restfulapi.net/resource-naming/

REST Resource Naming Guide

---

[출처]

 

강의 : 

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

 

참고링크 :

* 델리게이션(Delegation) 문제를 고려할 것

https://velog.io/@ellyheetov/Delegation