1. API URI 생성하기
- 리소스 식별이 가장 중요!
- 회원을 등록하고, 수정하고, 조회할 때 리소스는 회원이다!
- 회원 조회 /members/{id}
- 회원 등록 /members/{id}
- 회원 수정 /members/{id}
- 회원 삭제 /members/{id}
- 리소스(회원)과 행위(조회, 등록, 수정, 삭제) 분리!
2. HTTP 메서드
2-1. GET
- 리소스 조회: 클라이언트가 get으로 요청 보내면 서버가 /members/100에 있는 데이터를 클라이언트로 응답해줌
2-2. POST
- 요청 데이터 처리(username, age데이터를 넘겨줄테니까 처리해줘)
- 메시지 바디를 통해 서버로 요청데이터 전달
- 보통 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
- 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함(정해진 것이 없음)
- 새 리소스 생성(등록)
- 요청 데이터 처리
- 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우 사용
- 이때, POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
- 다른 메서드로 처리하기 애매한 경우
- 조회는 최대한 get을 사용해야하지만, 어쩔 수 없을 때 post 사용
2-3. PUT
- 리소스가 있다면 완전히 대체(내용 덮어버림!)
- 리소스가 없으면 새로 생성
- 클라이언트가 리소스 식별
- POST와의 차이점!
- post는 /members에 넣으면 서버에서 100, 200에 만들지 클라이언트는 모름
- put은 클라이언트가 리소스를 지정한다 -> /members/100에 넣을거라고 서버에 알려줌
2-4. PATCH
- 리소스 부분 변경
- 만약 http에서 patch를 받아들이지 못하면, post사용해라 -> post는 무적
2-5. DELETE
3. HTTP 메서드의 속성
3-1. 안전
- 호출해도 리소스를 변경하지 않음
- get안전 + 나머지 안전하지 않음(변경이 일어나기 때문)
3-1. 멱등
- 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다
- GET, PUT, DELETE는 멱등
- POST는 멱등 아님! -> 두번 호출하면 같은 결제가 중복해서 발생할 수 있음
3-1. 캐시가능
- GET, HEAD, POST, PATCH 캐시가능(실제로는 GET, HEAD 정도만 캐시로 사용)
- 캐시 하려면 키가 맞아야함 -> 똑같은 리소스와 키가 맞아야하는데 post는 body안에 데이터까지 고려해야하므로 쉽지않음
4. 클라이언트에서 서버로 데이터 전송
4-1. 데이터 전달 방식
- 쿼리 파라미터를 통한 데이터 전송(get)
- 메시지 바디를 통한 데이터 전송(post, put, patch)
4-2. 클라이언트에서 서버로 데이터 전송 상황
[ 정적 데이터 조회 ]
- 보통 쿼리 파라미터 없이 리소스 경로로 단순하게 조회
[ 동적 데이터 조회 ]
- 쿼리파라미터(q=hello&hl=ko)를 클라이언트가 넘기면, 서버가 받아서 쿼리파라미터를 key-value로 뽑아낼 수 있음 -> 그 결과를 서버가 응답
- 주로 검색, 정렬에 주로 사용
- GET, POST만 가능!
- POST전송 - 저장
- form의 데이터를 읽어서 http메세지를 생성
- 이때, username=kim&age=20는 쿼리파라미터랑 거의 동일한 형태로 서버에 전송함 -> 서버에 들어오면 데이터 저장
- GET전송 - 저장
- get이니까 메세지 바디안쓴다했다
-> 그래서 쿼리파라미터에 넣어버려서 서버에 전달
[ HTTP API를 통한 데이터 전송 ]
- POST, PUT, PATCH: 메시지 바디를 통해 데이터 전송
- GET: 조회, 쿼리 파라미터로 데이터 전달
5. 기타 알아둘 것
- 대부분 PUT보다 POST기반 등록을 많이 사용
- PUT은 파일 업로드 서버에서 사용(파일은 수정하는 것보다 덮어쓰는게 나음)
- 회원데이터를 전부 다 보내야 기존거를 덮어쓸 수 있음 -> PATCH쓰는게 제일 좋고 완전히 덮을 자신 있을 때 PUT
- PUT: 게시판 수정할 때 좋음
- POST: 이도저도 애매할 때 사용
- HTML Form은 GET, POST만 지원함
- 컬랙션
- POST기반 등록
- 서버가 관리하는 리소스 디렉토리
- 서버에서 보통 리소스 URI를 결정하고 만들어줌
- 회원등록할 때, POST/members로 {username : "young", "age" : 20}을 보내면 서버가 db에 저장 후 새로운 리소스를 members/100(신규리소스id)이라고 클라이언트에게 넘겨줌
- ex. 회원 관리 API 제공, 회원 관련은 /members
- 스토어
- PUT기반 등록
- 클라이언트가 관리하는 자원 저장소
- 클라이언트가 리소스의 URI를 알고 관리
- ex. 정적 컨텐츠 관리, 원격 파일 관리, /files
- 컨트롤 URI(실무에서 많이사용하지만, 남발하면 안됨)
- GET, POST만 지원(제약 존재)
- 이런 제약해결을 위해 동사로 된 리소스 경로 사용(ex. POST의 /new, /edit, /delete가)
