HTTP - GET, POST, PATCH PUT, DELETE 및 URI 설계 개념 사이트 추천

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗

https://inf.run/d6XMC

모든 개발자를 위한 HTTP 웹 기본 지식| 김영한 - 인프런 강의

 

내가 2년 전쯤에 구매해서 이제서야 다시 듣기 시작한 HTTP 강의다.

 

구매당시에는 다들 "필요하다고 해서" 사긴 했는데,

뭐때문에 배우는지도 모르겠고, 별 흥미도 없어서 4개정도의 강의를 듣다가 묻어두었다.

 

하지만 이제와서 들으니 분명 유의미한 강의라고 보여서 HTTP 중 중요 부분 소개하고자 한다.

 

1.회원 관리 시스템

API 설계 - POST 기반 등록

 

-회원 목록 /members -> GET

-회원 등록 /members => POST

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

-회원 수정 /members/{id} -> PATCH, PUT, POST

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

 

이렇게 있을때 그 중에서도 중요한 부분은

 

PUT - 기존의 리소스를 "완전히"삭제하고, 다른 것으로 다시 엎는다.

예를들어서 기존에 스타벅스 회원정보로 이름, 전화번호가 입력되어 있을때,

회원 수정을 PUT으로 하게 되면, 기존의 정보를 완전히 날리고, 새롭게 입력하는 정보로 다시 덮는다.

 

현실적으로 회원 정보는 간단히 1,2개가 아니다.

그런데 7개가 입력이 되어 있다가 6개가 입력된다든지하면, 기존에 입력되어있던 1개의 데이터는 유실되게 된다.

그래서 "일반적으로는" PATCH가 좋다.

PATCH는 "수정한" 정보만 덮어 씌워지기 때문이다.

 

게시글을 사용하는 상황에서는 보통 PUT이 유의미하다.

 

하지만 위의 2가지 경우 모두 헷갈리면 그냥 POST를 쓰라고 한다.

 

내가 이해한 바로는

GET과 POST가 주류이고

GET = 정보"조회"류

POST = 덮어 씌워야 하는 류 및 GET, PATCH등으로 해결이 안될 때 최후의 해결사

정도의 느낌으로 봐도 무방한 것같다.

 

GET으로 정보조회를 하게 되면 "캐싱"이 남아서 조회에 용이하지만,

POST는 캐싱이 남지는 않아서 리소스 낭비가 심해지는 것 같다. 그래서 쿼리셋 조작시 우선순위에서 항상 밀리는 것같다.
"무겁지만 확실하게 끝내는 마무리투수" 느낌으로 연상이 된다.

---

2.디테일 설명

 

리소스 = 명사 개념이라고 한다.

이를테면 "책을 사라"라는 지시에서

책 = 리소스

사라 = 동사

가 되는 것이다.

 

이게 URI설계시 중요 개념이다.

 

책을 사라

책을 수정하라

책의 목록을 보여줘라

라고 되어있을때.

 

books/{id}/buy/

books/{id}/edit/

books/

 

이런식으로 표현될 수 있다.

---

3. POST와 PUT의 공통점 및 차이점

 

공통점

-리소스가 있으면 덮어쓰기 한다.

(기존의 리소스가 name, aga였고,

대체될 리소스가 age면

대체될 age만 덮여서 기존의 name을 날려주는 것이다.

-리소스가 없으면 생성한다.

 

차이점

-POST는 books/ 정도만 되어도 되지만

-PUT은 books/100 처럼 완전히 리소스의 위치를 알고 URI를 조정해줘야한다고 한다.

---

4.요약 정리

 

1)리소스 (명사)로 처리한다.

예: 회원관리, 회원조회 등은 /members/

 

2)리소스+동사 의 구조로 설계한다.

예: /members/{id}/

 

3)리소스 + 동사의 구조로 해결이 안되는 것은 컨트롤러 혹은 컨트롤 URI라는 개념을 쓴다.

명사+동사+동사 이다.

예: 등록된 특정 회원 삭제 시

/members/{id}/delete/

---

URI 설계 개념 설명 추천 링크

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

REST API URI Naming Conventions and Best Practices