HTTP 웹 기본 지식 (4) - URI 작명법, HTTP 메소드

김영한님의 HTTP 웹 기본지식을 들으며 정리하였습니다.

 

리소스란 ?

• 미네랄을 캐라. → 미네랄 자체가 리소스
• 회원 등록하기 → 회원이 리소스
• URI는 리소스(명사)를 식별할 수 있어야한다.
• 행위는 메소드가(GET, POST ...) 해결해줄 것이고, 리소스는 명사로서 생각한다.

좋은 URI 설계 규칙

1. 명사로 작성하기. 동사 X (하지만 어쩔 수 없이 동사를 써야하는 경우가 있음. 이걸 컨트롤 URI라고 함.)
2. 마지막에는 슬래시를 쓰지 않는다.
3. 언더바(_)보다는 하이픈(-)을 사용한다.
4. 파일 확장자는 URI에 포함하지 않는다.
5. 계층 구조상 /abc/xyz/pq 상위는 컬렉션으로 보고, 복수 단어를 사용하기 권장한다. member → members

컨트롤 URI

• 동사로 된 리소스 경로를 의미함.
• /members/{id}/delete 라고 써놓고 POST를 날리는 상황에서 컨트롤 URI를 썼다고 할 수 있음.
• 최대한 리소스 중심의 URI 설계를 하고, 정 안될 때만 컨트롤 URI를 사용함.

HTTP 메소드 (클라이언트가 서버로 이거 해주세요~ 요청)

• GET : 리소스 조회
  
  • GET으로 서버에 데이터를 전달할 때는 쿼리를 통해서(쿼리 스트링, 쿼리 파라미터) 전달한다. HTTP 메세지 바디를 사용해서 데이터를 전달할 수도 있지만 지원하지 않는 곳이 많아서 권장하지 않음.
  • GET으로 오는 건 캐싱이 가능하다. 생각해보면, 로그인할 때 아이디 비밀번호 POST로 보내는데 이런거를 캐싱하진 않을테니. 그래서 GET, POST 이런 메소드의 구분이 중요한 것임.
• POST : 데이터 처리해달라고 요청.
  • HTTP 메세지 바디를 통해 서버로 데이터를 전달한다.
  • 주로 데이터 등록같은 역할인데, 회원가입, 게시판글쓰기, 신규 등록, 내용 추가 등 여러 방면으로 사용 가능하고 요청 데이터를 어떻게 처리할지는 상황에 따라 다름.
  • 조회할 때 어떤 내용이 json같은 형식으로 필요한 경우, 조회인데도 POST를 쓸 수도 있음. 쿼리 파라미터로 데이터를 다 넘길 순 없으니 POST 쓰는 거고, 이럴 땐 메세지 바디에 조회용 데이터를 넘기면 된다.
• PUT : 리소스 대체(덮어 씌우기), 리소스가 없다면 새로 생성
  • 파일을 폴더에 넣는 것과 비슷함. 파일이 없으면 폴더에 새로 생성하는 거고, 이미 있다면 덮어 씌우는 것.
  • 리소스가 있다면 → 리소스를 "완전히" 대체함, 덮어 씌우는 형식이라 기존 것을 통째로 없앰. 그래서 A=10 , B=20이라는 정보가 있는 곳에 PUT으로 A=30을 보내면, B 요청은 안보냈으니 B는 아예 날아가고 최종적으로 A=30만 저장되게 됨. (주의!!)
  • 리소스가 없다면 → 새로 생성함
  • 클라이언트가 구체적인 리소스의 위치를 알고, 지정하는 것임.
• PATCH : 리소스 부분 변경
  • 간혹 PATCH를 지원 안하는 서버도 있는데, 그럴 때는 POST를 사용하면 됨. POST는 자유도가 높다.
• DELETE : 리소스 삭제

HTTP 메소드의 속성

출처 https://ko.wikipedia.org/wiki/HTTP

• 안전 (Safe) : 호출해도 리소스가 변경되지 않음.
  • GET은 안전, POST , DELETE 이런건 당연히 안전하지 않음.
  • 주의) 리소스 변경 여부만 고려하는 맥락이라 GET요청 계속 보내서 장애가 발생하는 측면은 고려하지 않음.
• 멱등 (Idempotent) : f( f(x) ) = f(x)   몇번을 호출하든 결과가 똑같다.
  • GET, PUT, DELETE : 멱등 → PUT은 계속 결과를 덮어 씌우는 것이라 멱등임.
  • POST : 멱등 아님.
  • 멱등의 활용 : 자동 복구 매커니즘 ex) DELETE 요청했는데 응답이 없음. 이때 DELETE를 다시 요청해도 되는가? 를 생각해볼 때, DELETE는 멱등이기 때문에 같은 요청 2번 해도 된다.
  • 주의) 외부 요인은 고려 안함. 오로지 내가 요청한 것에 대한 결과를 생각한 것. GET (POST) GET 했을 때, 중간에 다른 사람이 POST 날리면 두번째 GET에서는 다른 리소스가 보여질 수 있지만 그런건 고려 안함.
• 캐시 가능 (Casheable)
  • GET은 캐싱이 가능. URL만 키로 잡고 캐싱하면 되서 심플하다.
  • POST, PATCH도 캐시가 가능은 하지만 구현이 복잡해서 캐시로 잘 안씀.