back

http (3) - Http 메서드 / 메서드 활용

ex) 요구 사항: 회원 정보 관리 api 만들기 (회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제)

- uri 설계시 가장 중요한 것은 리소스 식별

- post는 메세지를 내부에 담아 보낼 수 있는 모든 것을 할 수 있지만, 조회는 get이 유리(캐싱 가능), 변경되거나 프로세스가 진행되거나 어쩔 수 없는 경우에 post사용

- 멱등은 자동 복구 메커니즘에 활용(ex: delete를 호출했는데 서버에서 응답 없음 > 클라이언트가 재시도, 멱등한 요청이기에 문제 없음)

- GET은 url을 키로 잡고 캐시를 하면 됨(실무에선 주로 get만 캐시로 사용)

2-1

- 이미지, 정적 텍스트 문서 같은 경우, 조회이기에 GET 사용, 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

- 위 http 메세지를 보면 save(리소스 변경)이기에 get 사용 불가

- 서버끼리의 통신은 html 같은게 전혀 없음(기계끼리의 통신이기 때문)

- get은 쿼리 파라미터로 post는 메세지 바디로 데이터 전달

2-2.

컬렉션

- 검색 조건이나 정렬 조건도 쿼리 파라미터로 설정 가능

- /members 를 컬렉션으로 부름

- 회원 수정은 경우에 맞춰 메서드 사용(patch가 주로 적절함)

- put이 적절한 상황 ex: 게시판 글 수정(게시글 수정하면 완전히 덮어씌어짐)

- post를 통해 특정 컬렉션에 신규 데이터를 등록한다고 서버에 요청하면 서버가 요청을 받아 db에 저장, 그 후 신규 리소스를 식별할 수 있는 uri를 서버가 생성 그리고 응답할 때 location의 값으로 넘겨줌 또는 메세지 바디에 id 형식으로 넘기기도 함

- post로 데이터 등록할 때는 서버에서 리소스 uri를 결정하고 생성함

스토어

- 파일은 중복이 안되고 덮어씌우기에 위 상황에서는 등록으로 put을 사용함

- put은 클라이언트가 리소스 uri를 알고 등록함, 서버는 오는대로 처리해주는 것일 뿐

- 대부분 post 기반의 신규 자원 등록을 사용 (컬렉션 사용), put은 파일 업로드, 게시글 수정등의 소수의 목적으로만 사용됨

ex: 회원 등록이라는 버튼을 누름

> /members/new 링크로 연결

> 회원 등록 폼에서 정보 입력 후 저장 버튼 클릭

> post 필요 (1. /members/new 를 폼을 등록할 때는 get 사용하고 실제 데이터 저장시엔 post 사용, 경로 유지 장점이 있어 추천

2. 폼 등록시에는 /members/new 사용하고 실제 등록시엔 컬렉션을 자원으로 관리하는 것처럼 /members 를 post넘기기 )

- 회원 수정 폼과 회원 수정 동작 또한 위의 설명과 같이 경로 설정이 가능하다. (마찬가지로 폼과 동작의 url을 통일하는것 추천)

- 삭제같은 경우도 post로 처리하는데, delete메서드 사용이 제한되므로 컨트롤 uri사용

- 무작정 컨트롤 uri 사용보단 최대한 리소스를 사용해 설계를 하고 그 상황에서 안될 때 컨트롤 uri를 대체제로 사용

- /files 경우에 클라이언트가 전체 uri경로를 put메서드 이용해 넣음

- 컨트롤 uri는 주로 데이터를 조작/변경하는 일이기에 동사 이용

편리한 uri 생성 위한 기준

1. 리소스는 명사(ex: 회원/주문, 복수형)

2. 상세정보(회원번호/주문번호)를 가지고 해결이 안되는 상황은 컨트롤 uri 사용

- 컬렉션이나 문서를 가지고 최대한 해결(get/post/put/delete)을 하고 안될때 컨트롤 uri 사용

Contents

새소식