REST API 정리. (필기, 퍼온 글)
출처1 https://youtu.be/PmY3dWcCxXI
출처2 https://taetoungs-branch.tistory.com/155
출처3 https://blog.naver.com/comingdown/222163745128
웹브라우저에서 웹서버에 Ajax를 위한 API인 'fetch'를 이용해서 'REST API'를 이용하는 방법을 소개한다.
Ajax와 fetch에 대해 알고 싶다면, 이글을 참고해보자! : https://cocoon1787.tistory.com/756
왼쪽 : 데이터가 들어있는 '웹서버' // 오른쪽 : '웹브라우저'
#데이터 생성 - POST
title이 'fatch'인 데이터(문서)를 "topics"라는 리소스에 추가하려고 함!
- 이 데이터를 json 형태로 바꿀것이기 떄문에, 서버에 이를('내가 만든 데이터는 json이야'를) 알려주기 위해
{ 'content-type':'application/json' }, 이라고 작성함!
- 이때 중요한 것은! : 우리가 추가할려는 저 데이터는 "topics"라는 리소스에 "추가"할려고 하는 것이다!
때문에, 데이터의 주소는 'topics'라고 젤 앞부분에 명시해 둔다!(리소스를 식별!!!)
- 그리고 우리가 할려는 것은 데이터를 생성할려는 것인데, 생성이 HTTP프로토콜에서는 POST기 때문에, method:'POST' , 라고 적어둔다. 라는 것이 'REST API의 권고안'인 것이다!
(json/xml은 REST와 무관. topics와 'POST'가 중요!!!)
데이터가 잘 추가됐다.(리소스가 'POST'됐다!)
(스크린샷엔 없지만) status는 201이라고 뜨고,
우리가 방금 추가한 데이터도 아래에 출력됐다!
topics에서 클라이언트와 서버가 통신한 내용을 자세히 보면서,
어떤식으로 HTTP request와 response가 이루어지는지를 살펴보자!
REST API를 이용했을때 말이다!
method: POST(생성하기) , URI : /topics 가 가리키는 데이터(리소스)가 우리가 생성 할려는 데이터! 그리고 실제 내용도, view source를 보면 나온다!
content-type 이 json인 것도 나온다. ( 때문에 서버는 얘를 json의 형태에 맞게 파싱해서, 여러가지 처리를 알아서 해준다. )
자 그럼, 서버는 이 클라이언트에게 응답을 할 것인데,
응답의 구체적인 메세지를 보면(view source클릭), 201이라는 응답코드를 보내줌!
201 : 데이터의 생성이 성공적으로 끝났다는 것을 서버가 클라이언트에게 알려줄때 사용하는 약속된 번호.(HTTP상태코드 중 하나!) 또한 이 약속된 번호 201 의 이름이 'Created'인 것이다!
즉, REST API의 핵심은 '서버쪽에서 어떠한 일을 처리하고, 그 처리한 일의 결과를 보고있는 것처럼 응답코드와 응답메시지를 통해서 응답하자 라는 것'이다!
이렇게해서 클라이언트에게 응답한 데이터는 'Response'에 있는 데이터다. 이 데이터가 어떤 테이터타입인지를 서버가 클라이언트에게 알려주기 위해서, Response Headers의 content-type 이 json인것을 이번엔 서버가 클라이언트에게 알려주고 있다!
다시 정리,
REST API에서
-규정(권고)하고 있는것:
1. 리소스를 식별할때는 이렇게 URI를 통해서 식별하라( /topics )
2. 어떤 행위를 할때는 POST GET PUT/PATCH DELETE 와 같은 HTTP의 고유한 메소드를 이용한다.
3. 결과를 알려줄 때는 응답코드(201)를 정확하게 사용하는 것을 통해서 결과를 알려준다.
즉, 'HTTP프로토콜을 HTTP프로토콜 답게 사용하자는 것'이 REST API가 주장하는 바!
-규정하지 않는 것: 클라이언트와 서버가 어떤 데이터타입으로 통신할것인지(JSON, XML 등등)
#콜렉션(여러개의데이터 한번에) 읽기 - GET
200 OK
GET /topics
#부분 읽기(한건 한건의 구체적인 데이터) 읽기 - GET
'topics/2' 이렇게 이 데이터의 식별자(id)를 '리소스명/ ' 뒤에 적어줌!
원하는 엘리먼트 (ID=2) 가 잘 읽어와짐!
GET /topics/2
200 OK (스샷엔 없지만)
#부분수정 - PATCH
이상태에서(title부분을 주목), 아래의 사진과 같이 부분수정됨!
"title": "fetch" 에서 "title": "fetch - patch" 로 성공적으로 수정됨!
title 만 수정! -> body와 id는 그대로!
PATCH /topics/2
200 OK
#전체수정 - PUT
마찬가지로 'topics/2' , title 만 언급했는데 !
title과 id만 살아있고, body는 사라지게 됨!
즉, PUT 은 우리가 '전송한 그 데이터'로 전체를 교체하는 것!
식별자인 id를 제외하고 내가 언급하지 않은 데이터는 삭제된다!
#삭제 - DELETE
'topics/2'
method: 'DELETE'
실행하면 단순히 삭제가 된다!
이렇게 특정 엘리먼트만 삭제를 할때가 있고, 콜렉션 전체를 삭제할 때도 있다.
'topics'
method: 'DELETE'
허나 이는 위험하기 때문에 막혀있는 경우가 대부분이다!
#관계 : 리소스와 리소스가 관계를 맺고 있을때 걔를 URI로 어떻게 표현할 것인가?
이를테면 topics는 comments(댓글)을 포함하고 있다.
그리고 comments는 'topicId'를 통해서 topics의 "REST"라는 title의 글 하나에
종속돼있는 관계를 맺고 있다.
'topics / 1 / comments'
'부모리소스명 / 부모엘리먼트의id값 / 자식리소스명'
이렇게 URI로 적어서 표현한다!
약속인 것!
이것이 REST API 이다!
REST API는 그렇게 복잡한 권고안이 아니다. 기계와 기계가 HTTP를 이용해서 통신할때,
리소스는 'URI'로, 행위는 'method'로, 결과는 '응답코드'로
HTTP가 원래 가지고 있는 의미를 잘 활용하자는 것!
################################################################################################
REST(ful) API :
어떤 기술이나 제품이 아니라, 형식이기 때문에 어떤 언어를 쓰든 상관이 없음
특정 기술을 의미하는 것이 아니기 때문이다!
각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하게 하는 것.
예를 들어, https://(사이트도메인)/1이라는 주소가 '클래스 정보 리스트 출력' 기능을 수행한다고 할 때,
사실 만드는 개발자의 입장에서는 잘 수행하기만 하면 그만이겠지만,
인수인계를 받는 개발자나 혹은 해당 API를 사용해서 다른 제품을 만들 개발자들은
해당 주소만을 보고 이 API가 어떤 기능을 수행하는지 쉽게 파악하기 어려움
RESTful하게 만든 API는 요청을 보내는 주소 만으로도 대략 이 기능에 대한 파악이 가능함!
https://(사이트도메인)/classes/2/students?sex=male 라는 주소가 있다면
'2반에 소속된 남학생들의 정보를 출력'하는 요청을 전달했다는 것을 파악할 수 있음!
서버에 REST API로 요청을 보낼 때에는 HTTP 규약에 따라 신호를 전송
HTTP메소드 중 GET, POST, DELETE, PUT (,PATCH)를 사용하여 작성함
- GET : 상세 정보 출력
- POST : 정보 추가
- PUT/PATCH : 정보 수정 (PUT은 정보를 통째로 변경, PATCH는 일부를 특정 방식으로 변경하는 경우 사용)
- DELETE : 정보 삭제
################################################################################################
