[네트워크] HTTP 메서드 활용

728x90

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

데이터 전달 방식은 2가지

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

- GET

- 정렬 필터(검색어)

query=\(검색어)

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

- POST, PUT, PATCH

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

1. 정적 데이터 조회

- 쿼리 파라미터 미사용

추가적인 데이터를 전달하는 게 없고, URI 경로만 넣으면 추가적 데이터가 필요 없어서 이미지 리소스를 클라한테 보여줌

- 이미지, 정적 텍스트 문서는 단순 조회라서 GET 사용

- 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

⭐️ Path Parameter 바이브

api/v1/post/(postId)

2. 동적 데이터 조회

- 쿼리 파라미터 사용

검색어 같은 추가 데이터 전달할 때

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

- 조회 조건을 줄여주는 필터(=검색)

- 조회 결과를 정렬하는 정렬 조건에 주로 사용

- 조회는 GET

- GET은 쿼리 파라미터 사용해서 데이터 전달

⭐️ Query String 바이브

auth/user?id=1234

auth/login?token=\(accessToken)

3. HTML Form 데이터 전송 (웹에서사용) - GET/POST만

1) POST 전송 - 저장

form의 데이터를 읽어서 HTTP 메시지를 생성해줌

쿼리 파라미터랑 거의 유사한 형식으로 key-value 형식으로 HTTP Body에 넣어서 서버에 전송

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

- 전송 데이터를 url encoding으로 처리 : 한국어가 들어가면 %~ 인코딩 되어서 넘어감

2) GET 전송 - 저장

GET은 메시지 바디를 안쓰니까 쿼리 파라미터로 넣어버림 그리고 서버에 전달

-> 여튼, 웹 브라우저가 HTTP Method에 따라 POST면 쿼리 파라미터, GET은 메시지 바디로 전송한다.

3) multipart/form-data (알자놔~~~)

파일 업로드 같은 바이너리 데이터를 전송할 때 사용

여러 다른 종류의 파일과 폼의 내용을 함께 전송해서 multipart라고 부름

GET, POST만 전송한다.

HTTP API 데이터 전송 (우리가 아는 방식~) - 전부다 가능

클라에서 서버로 바로 데이터 전송할 때

- 서버 to 서버 : 백엔드 서버 통신할 때

- 앱 클라이언트 : 아이폰, 안드

- 웹 클라 : HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용 - AJAX

- POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송

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

- Content-Type : application/json이 표준 (원래 xml을 썼었는데 10년 전 쯤에.. 지금은 json이 표준됨)

HTTP API 설계 예시

✔️ 1. HTTP API 컬렉션 - POST 기반 등록 - 회원관리시스템에서

PUT : 기존 리소스를 거의 덮어버리는 것 (게시판의 게시글 수정할 때 쓰면 됨)

PATCH : 부분 수정 (개념적으로 이게 제일 좋음)

POST : 완전히 덮어도 된다면 이걸 써도 됨 (애매한 경우 천하무적 POST 써라~)

회원 관리 시스템에서 정리하자면,

POST의 경우,

<데이터 등록 시에는 서버에서 데이터 URI를 결정하는 바이브였음>

즉, 클라는 등록될 리소스의 URI를 모름 - 클라가 결정하는 게 아니니까!

서버가 Location: /memebers/100이라고 등록을 해줌

이런 형식을 컬렉션이라고 함

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

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

- 여기서 컬렉션은 /members

2. HTTP API 스토어 - PUT 기반 등록 - 파일관리시스템에서

파일 등록은 PUT을 써서 : 기존 것을 덮어버림!

이전과 다른 것은 신규 자원 등록 시에 PUT이라는 걸 쓰고 있다!

PUT의 경우,

<데이터 등록 시에 클라이언트가 리소스 URI를 알고 있다.>

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

- files/star.jpg

- 클라가 직접 리소스의 URI를 지정

이런 형식을 스토어 Store

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

- 여기서 스토어는 /files라는 경로

🔴POST는 /members로 넘기면 서버가 회원의 id를 만들고,, 서버가 판단해서 만들어줌 - Collection
🔵PUT은 클라가 등록될 리소스의 URI를 다 관리해야 함 - Store

긍까, POST는 서버가 다 알아서 해줘서 클라는 아무 것도 모름

PUT은 클라가 알아야 하고, 관리를 해야 함

**둘 중 POST를 대부분 씀 ^^*...**

3. HTML FORM 사용 - GET/POST만 지원 - 제약 존재 - Control URI

순수한 HTML FORM을 이용하면 GET/POST만 사용하고,

AJAX를 통해서는 다른 것도 가능하긴 함.

일단 여기서는 HTML FORM 기준으로 말하겠음

영한님은 회원등록 폼과 등록을

- /members/new (GET, POST로) 같게 맞추는 경우를 선호한다고 하심

수정 폼을 보는 건 GET

수정하는 건 데이터가 전송되어야 하기 때문에 POST이고 영한님은 같게 맞추는 걸 선호

삭제는 POST (Delete를 못쓰기 때문에 URI 경로로 표현)

컨트롤 URI를 통해 표현

- GET/POST만 지원하기 때문에 제약이 있음

- POST의 new, edit, delete 처럼 동사로 된 리소스 경로 사용

- HTTP 메소드로 해결하기 애매한 경우

개발할 때는 거의 대부분 POST를 쓰는 컬렉션이라고 한다...

컨트롤 URI는 필수로 있어야 한다, 없을 때를 위한 것이니까,, HTTP API에도 굉장히 많이 필요하니까.

결국은 사실 서버 통신하면서 많이 실습하면서 개념을 떠올리면 될 것 같다. 강의에서 이야기하던 그거구나..라는

글구 리소스는 미네랄을 캐는 거다.