DRF__이해__(2)

1. HTTP 메서드를 기준으로 작업 정의

매번 느끼는 거지만, 개발 용어는 딱딱하고 인간미가 없다.;;;

작업 정의라니 참.. 나만 이상한가?

에이 익숙해질 때 까지 공부하자

(앞번에 배운 내용이지만, 복습을 위해 읽고 머릿속에 동작을 그려본다.)

이렇게 F12(개발자 모드) 에서 Network탭에 들어가보면 내가 요청한 목록들이 나온다. 사진에는 css파일로 필터링 되어서 저렇지만, 모두 보기도 된다.

Status에 200이라는 숫자가 있다.

요청이 정상적으로 완료되었다는 의미이다. 

현재 티스토리 서버에는 onlythisone.tistory.com/manage/newpost/44?type=post&returnURL=https%3A%2F%2Fonlythisone.tistory.com%2Fentry%2FDRF%25EC%259D%25B4%25ED%2595%25B42 이라는 url에 사진과 같은 정보가 저장되어 있다.

해당 url과 함께 GET 메서드가 요청을 하면 해당되는 정보를 뿌려줄 준비를 하고 있는 것이다.

요청한 목적지(나)에 정상적으로 도착하면 전송 완료 코드 200을 보낸다.

 

POST는 안되네; 새 글을 썼는데 201 상태코드가 안나온다;

난 아직 애송인가보다. 계속 하다보면 이유를 알게 되겠지.. 일단 패스한다.

 

위 5가지 메서드는 아래와 같이 사용 가능하다. (예시)

customers 리소스에 대해 POST 메서드를 실행하게 되면 숫자 1과 같이 고객 한 명을 만들고, primary key 하나를 부여할 수 있다.

반면 customers 리소스에 GET 메서를 실행하게 되면 고객 리스트를 가져온다. 하위 경로를 주면 세부 정보를 가져오는 것이다.

더 하위로 가면 주문목록을 본다.

PUT을 하게 되면 고객 정보를 바꾼다. 먼저 POST로 고객 정보를 생성하고, 고객 정보 수정 창으로 이동하기 위해 GET을 사용하고, 정보를 수정해서 PUT을 사용한다.

필요없게 된 고객 정보는 DELETE로 삭제한다.

PUT과 PATCH 메서드의 차이가 모호하다. 그래서 검색을 해봤다.

출처 - https://papababo.tistory.com/269

 

그렇다고 한다. 깔끔하게 정리를 참 잘하셔서 내가 더 할 게 없다. 이런 인재가 되고 싶다.

아니, 능가하고 싶다.

 

그러나 또 문제가 생겼다.

이상한 소리를 한다.

idempotent? 처음 듣는 말이다.

하지만 지금은 2020년 그리고 난 IT 강국에서 살고 있다.

구글 번역기로 간다.

 

 

. . . .?

흐음.. 멱등.. 난 한국어를 이해 못하고 있는 한국인이다.

 

다시 검색을 한다.

 

멱등이란 훌륭한 의미를 가지고 있었다!

결국 PUT 요청은 멱등이어야 한다.

POST나 PATCH는 원본은 그대로 사용하지 않는다. POST는 새로운 내용을 올리는 것이고,

PATCH는 원하는 데이터만 바꿔서 올리면 된다.

반면, PUT은 모든 원본 데이터를 다 가져오고, 거기서 일부부만 수정하여 업데이트한다.

이게 PATCH랑 뭔 차이지?

 

아래가 멱등에 대한 해답이다.!!

출처 - https://m.blog.naver.com/PostView.nhn?blogId=k_builder&logNo=40173155123&proxyReferer=https:%2F%2Fwww.google.com%2F

거참 멱등이면서 멱등인지 않은 것이네..

오케이 GET과 HEAD는 원본을 해치지 않구나 그래서 안전하다.

그 외에는 원본을 변형하니까 안전하지 않다.

근데 멱등은 왜 낀거래? 노 이해

 

 

2. HTTP 의미 체계 준수

HTTP 세부정보는 HTTP 사양 참조 ㄱㄱ

또 다시 등장한 우리 JSON 형님, 그리고 XML형식

저런식으로 주고 받을 데이터의 형식을 지정한다.

 

 

- HTTP 상태 코드

어느 웹사이트를 가건 200 코드를 볼 수 있다.

아까 티스토리에 새 글을 올렸는데, 201 코드를 반환하는 녀석은 없었다. 뭐가 문제인걸까

201 코드를 반환하지 않은 이유는 이것일까? 아니야.. 새 URI가 생겼단 말이지...

흔히 보는 404는 보이지 않네, 대신 400 코드가 있다. 앞자리 숫자에 따라 성공인지 실패인지 서버 문제인지 구분한다.

필요에 따라 다양한 코드가 준비되어 있다. 성찬식을 즐기듯 하나 쓱 꺼내 보내주면 된다.

말이 쉽지 처음 하는 사람은 느릿느릿 설정하는 데 속 터지겠다.

 

 

휴 하다보니 끝이 났따;

덜렁

 

 

REST 이해 1편 2편을 요약하자면, 아래와 같다.

 

1/3 정도가 남았지만, 세부적인 관리에 대한 내용인 듯 하다.

이정도면 REST API에 대한 이해는 끝난것같다.

핵심은 웹에서 CRUD를 할 것인데, HTTP 통신을 통하여 5가지 메서드를 이용하여 JSON 형식이든 XML 형식으로 데이터를 포장하여 서버와 주고 받을 것이다.

통신이 정상적으로 이루어졌다는 것에 대한 상태코드

통신이 비정상적으로 이루어졌다는 것에 대한 상태코드를 명시하고 있음으로,

개발자는 적절한 상태코드로 클라이언트에게 URI에 대한 결과가 어떻게 됐는지 알려주면 되겠다.

 

생각나는대로 의식의 흐름대로 막 쓴 것이므로,

이 외에 쓰지 못한 부분은 놓친 부분이므로 실제 사용해보면서 다시 공부하게 된다면 보충하면 될 듯 하다.

여기서 REST API 이해를 마치겠다!