REST API

REST API의 등장

WEB(1991)

Q: 어떻게 인터넷에서 정보를 공유할 것인가?

A: 정보들을 하이퍼텍스트로 연결한다.

    표현형식: HTML

    식별자: URI

    전송 방법: HTTP

 

HTTP/1.0 (1994-1996)

Q: 어떻게하면 웹을 망가트리지 않고, HTTP를 향상시킬수 있을까?

A: HTTP Object Model

 

REST(1998 -> 2000) 로이피딩의 박사논문으로 REST가 세계에 등장

 

XML-RPC 마이크로소프트 -> SOAP

Salesforce API 2000 -> 장사잘안됨, 넘 복잡.

flick API 2004 -> REST가 훨씬 짧다.

 

SOAP -> 복잡하다, 규칙많음, 어렵다.

REST  -> 단순한다, 규칙적음, 쉽다.

 

 

REST API의 승리

 

REST 아키텍쳐를 따르는 API

REST -> 분산 하이퍼미디어 시스템(ex. 웹)을 위한 아키텍쳐 스타일

 

아키텍쳐 스타일? 제약조건의 집합

유티폼 인터페이스를 잘 만족 못함

이를 위해, 좀더 규격화되게 REST를 사용해야 진짜 REST

 

출처: dev2017 유튜브

 

 

REST API의 정의

REST API: 컴퓨터의 명령을 실행시키는 기능, 남의 컴퓨터를 실행시키는 기능

인터넷과 웹을 통해 나의 컴퓨터를 제어할 때, 어떻게 하면 시행착오를 줄이고, 더 좋은 API를 만들수있을까에서 시작.

비유: http를 통해, 기계들이 통신할때의 모범사례

 

데이터(resource)

resource는 uri로 표현 이때, 전체를 표현하고 싶다면 -> collection

    ex. http://example.com/topics

한건한건의 데이터 -> element(collection은 element의 집합)

    ex. http://example.com/topics/1

    ex. http://example.com/topics/rest

 

정보의 가공(method)

CRUD, HTTP 규격의 명령!

Create  ---> POST

Read    ---> GET

Update ---> PUT | PATCH

Delete  ---> DELETE

 

 

테스트

 

웹브라우저에서 웹서버에 ajax를 위한 api인 patch를 이용해 REST API를 사용하는 법을 확인해보자.

브라우저와 서버가 통신하는가

개발자모드(F12) - Network 탭에서 확인!

 

리소스 생성(POST)

topics를 이용해 리소스서 생성

자세히 보기 위해서 topics라는 클라이언트와 서버가 통신한 내용을 들여다보자.

어떤식으로 request와 response가 되는지 보자.

 

요청의 실제 내용을 보려면, view source를 클릭한다. 그러면, 브라우저 서버가 통신한 실제 내용을 확인할 수 있음.

 

브라우저는 서버한테 보내는 내용은 Request Headers에서 확인 가능.

 

 

 

 

서버는 어떤 내용을 받았는지 보려면, Response Headers를 확인.

클라이언트에게 응답을 해야함.

 

 

클라이언트한테 응답한 데이터의 내용은 Preview, Response 등에서 확인 가능.

 

 

 

리소스 읽기(GET)

결과값

 

부분수정(PATCH)

전체수정(PUT)

식별자인 id만 제외하고, 전체가 바뀌어버림.

 

삭제(DELETE)

 

REST API에서 규정하지 않는것!

* 서버와 클라이언트가 어떤 데이터 타입으로 통신하는지 규정하지 않음 ex. xml, json 등

 

REST API에서 규정하는 것!

* 리소스를 식별하는 것은 url를 통해 식별한다.

* 어떤 행위를 할때는 POST, GET, DELETE, PATCH 등과 같은 고유한 메소드를 쓴다.

* 결과를 알려줄 때는 응답코드와 응답메시지를 남긴다.

 

REST API의 궁극적인 목표. -> HTTP 프로토콜을 HTTP 프로토콜답게 사용하자! 

 

출처: www.youtube.com/watch?v=PmY3dWcCxXI