| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 인터넷 네트워크
- port
- 자료구조
- 티스토리챌린지
- 알고리즘
- 자바
- 기초 개념 잡기
- Class
- 과장님 죄송했어요
- 생성자
- 기본은 충실히
- 오블완
- queue
- 배열
- URI
- Stack
- URN
- array
- 김영한님의 모든 개발자를 위한 HTTP 웹 기술 인강 꼭 들어보세요
- 연결 리스트
- 객체
- HTTP메시지
- heap
- 이진트리
- servlet
- tcp
- Hashtable
- HTTP
- URL
- 을 통한 웹 브라우저 흐름
- Today
- Total
HeadCopter
본격! HTTP(2) 본문
- 이 글을 쓰기 위해서 인강을 듣고 , 검색을 하고 여러곳의 사이트에서 다른 개발자분들에게 지식을 구하고자 찾아봤는데
URI를 설계할 때 가장 중요하고 앞으로 내가 프로젝트를 만들어가면서 신경써야할 부분이 리소스 식별이라는 답을 얻었다.
- 그렇다면 도대체 URI를 설계할 때 가장 중요하다고 다들 입모아 말하는 리소스 식별이라는것은 과연 무엇일까?
- 여기서 말하는 리소스(Resource) 란 create, read, update, delete 같은 행위는 리소스를 뜻하지 않는다 .
예를들어
- 등록 / create-users{id}
- 조회 / read-users{id}
- 수정 / update-users{id}
- 삭제 / delete-users{id}
와 같이 URL을 설계한다고 가정할 때 여기서 사용하는 create, read, update, delete 가 아닌, users 를 우리는 리소스라 한다.
- 어떤 행위 자체가 아닌 users 라는 행위의 대상이 바로 리소스이다. 고로 위에 작성한 설계로 한다고 해도 요청을 수행하겠지만 , 좋은 설계는 결코 아니라는 뜻이다.
- 이 내용을 토대로 다시 위에 있는 URI를 설계해 본다면 이렇게 작성할 수 있다.
- 등록 / users{id}
- 조회 / users{id}
- 수정 / users{id}
- 삭제 / users{id}
- 이렇게 URI는 내가 명시해놓은 users라는 리소스만을 식별하게 된다.
그럼 등록, 조회, 수정, 삭제 라는 행위는 어떻게 구분하는가 ?
- URI는 리소스만 식별하고 HTTP 메서드를 통해서 행위를 분리한다.
HTTP 메서드의 종류
- 리소스만을 식별을 하여 설계한 URI에 대해서 HTTP는 각 행위에 대한 메서드를 제공한다.
- GET : 리소스 조회 ( 서버에 전달하고자 하는 데이터는 URL 뒤에 파라미터를 통해서 서버에 전달한다)
- POST : 요청 데이터 처리 ( 메시지 바디를 통해 서버로 요청 데이터 전달 )
- PUT : 리소스를 완전히 대체한다 만약 클라이언트에서 보낸 리소스가 이미 있는 경우에 PUT으로 보낸 데이터로 완전히 리소스를 대체하고 기존에 있는 데이터는 삭제해버린다.
( 서버에서 식별자 리소스를 지정해주는것과 다르게 POST와 다르게 클라이언트가 리소스 위치를 알고 URI를 지정한다. ) - PATCH : 위에 PUT과는 다르게 PATCH는 기존 리소스를 대체하지 않고 부분만 변경한다.
- DELETE : 리소스를 제거한다.
HTTP 메서드의 속성
- HTTP 메서드의 속성은 이렇게 구성되어 있다.
- 안전(Safe Methods)
- 멱등(Idempotent Methods)
- 캐시가능(Cacheable Methods)
안전(Safe Methods)
- HTTP 메서드를 호출해도 리소스를 변경하지 않는다.
멱등(Idempotent Methods)
- 메서드여러번 호출하든지 결과는 같다.
(POST는 멱등이 아니다 데이터 등록으로 많이 사용하는데 호출할 때 마다 여러번 등록되고 중복이 되면 안되기 때문에.. )
- 서버에 응답이 없어서 클라이언트가 다시 재시도하더라도 영향이 없기 때문에 멱등을 활용한다 = 자동 복구 메커니즘
캐시가능(Cacheable Methods)
- 웹 브라우저를 통해 이미지를 요청했다고 가정했을 때 그 다음 똑같은 리소스를 요청할 필요가 없기 때문에 그런 이미지 같은 것들을 로컬 캐시 저장소에 저장한다 즉, 캐시가능이란 웹 브라우저에 요청한 이미지를 웹 브라우저 내 캐시 저장소에 저장할 수 있는가 없는가를 뜻한다.
- GET, HEAD, POST, PATCH는 캐시가 가능하지만 , 캐시를 하려면 KEY가 리소스와 일치해야 하는데 ,
POST와 PATCH는 Body안에 본문 내용까지 캐시 키로 고려해야 하기 때문에 쉽게 구현하기 힘들다.
공부를 마치며....
HTTP 관련 공부를 김영한님의 모든 개발자를 위한 HTTP웹 기술 인강을 통해 학습을 해봤는데
확실히 공부를 하기 전에 내가 바라보는 개발의 관점과 공부를 하고난 뒤에 바라보는 관점은 얼마 배우지는 않았지만
많이 차이가 나는 것 같다. 하루 공부를 하고서 공부한 내용을 다시 한번 정리하고 검색해보고 찾아보고 블로그를 작성하지만 하나 하나의 개념을 이해하기란 쉽지 않은것 같다.
그래도 눈에 익는 용어들이 많아지고 지식이 깊어지는 느낌은 언제나 항상 기분이 좋은 느낌이다.
이제 시작이니 더 꾸준히 더 열심히 노력하고 배워야겠다.
'개발관련' 카테고리의 다른 글
| MVC 패턴 정리1 (0) | 2022.07.27 |
|---|---|
| 서블릿(Servlet)이란 ? (0) | 2022.07.22 |
| 본격 ! HTTP(1) (0) | 2022.07.13 |
| 클라이언트 서버 구조 (0) | 2022.07.13 |
| URI, URL, URN 정리와 웹 브라우저 요청 흐름 ! (0) | 2022.07.12 |