API 란
어떤 기계를 만들면, 사용자가 그 기능들을 전부 활용할 수 있도록 제어장치를 마련해야 한다.
기계와 인간 간의 소통을 할 때는 TV의 리모컨, 컴퓨터의 모니터, 마우스, 키보드 등과 같이 인터페이스를 통해 소통할 수 있다.
소프트웨어와 인간 간의 소통을 할 때는 브라우저창, 슬라이더바 와 같이 UI를 통해 소통할 수 있다.
그렇다면 기계와 기계, 소프트웨어 소프트웨어 사이에서도 수많은 정보 요청이 이루어지고 있는데, 이들은 어떤 방식으로 소통할 수 있을까?
예를 들어, 기상정보가 관리되고 있는 기상청 서버가 있다. 날씨와 관련된 서비스를 제공하는 다양한 웹사이트, 앱들은 이 기상청 서버로부터 날씨 정보를 요청해서 받아가야 한다.
그런데 이 기상청 서버에 데이터를 요청할 때 지정된 형식이 있어야 한다.
"data:220508" | place:seoul | which:temperature"
이렇게 날짜와 지역, 조회할 내용을 표시해서 지정된 형식으로 요청을 하면,
"17 degree"
이렇게 답이 올 거라는 공개된 매뉴얼이 있다면,
누구든 이 매뉴얼을 참고해서 소프트웨어를 만들 수 있다.
즉 API (Application Programming Interface)는
'소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청받을 수 있는 수단'이다.
이러한 API는 왜 사용하게 되었을까? 프로젝트가 프론트엔드와 백엔드로 분리되기 시작하면서 resource를 json이나 xml과 같은 형식의 데이터로 받아오게 되었다. 이러한 데이터를 제공하는 방식이 API이며 View를 제공하는 대신 데이터를 제공한다.
그런데 API를 사용하다 보니 개발자마다 사용하는 매뉴얼이 달랐고, 혼자서만 개발하는 서비스가 아니다 보니 문제가 발생하게 된다.
이에 API에도 체계가 필요하 다해서 나온 방법이 REST API이다.
REST API 란
REST라는 형식의 API는 과거 SOAP이란 복잡한 형식을 대체한 것으로, 네트워크 구조의 한 형식이다.
REST의 가장 중요한 특성은 요청의 모습 자체로 어떤 정보나 동작을 위한 것인지 추론할 수 있다 는 것이다.
https://(도메인)/classes
https://(도메인)/classes/2
https://(도메인)/classes/2/students?page=2
이런 식의 URI는 요청의 모습 자체로도 반의 목록을 받아오는 요청, 2반의 목록을 받아오는 요청, 2반의 학생들의 2페이지를 받아오는 요청과 같이 어떤 정보를 요청하는 것인지 추론할 수 있다.
이렇게 resource를 구조와 함께 나타내는 형태의 구분자를 URI라고 한다.
URI는 단지 그 정보를 식별하는 이름일 뿐, 정보를 가공할 때는 4가지의 방법이 있다. resource를 Create, Read, Update, Delete(CRUD) 하는 4가지 방식이 있고, REST API에서는 이를 method라고 한다.
- Create(생성) : post
- Read(조회) : get
- Update(수정) : put(전체적으로 정보를 수정할 때), patch(특정한 정보를 변경할 때)
- Delete(삭제) : delete
서버에 Rest API로 요청을 보낼 때는 HTTP(HyperText Transfer Protocol)란 규약에 따라 신호를 전송한다. 우체국으로 무언가를 보낼 때도 일반 우편, 등기, 택배와 같이 여러 방식이 있듯이, HTTP로 요청을 보낼 때도 여러 메서드가 있다.
그중에서 REST API에서는 GET, POST, DELETE, PUT 혹은 PATCH까지 5가지를 사용한다.
post, put, patch는 body라는 주머니가 있어서 get, delete 방식보다 더 많이 그리고 비교적 안전하게 실어 보낼 수 있다.
POST 방식 하나로도 데이터를 CRUD 할 수 있다.
하지만 누구든 각 요청의 의도를 쉽게 이해할 수 있도록, RESTful 하게 API를 만들기 위해서는 이들을 목적에 따라 구분해서 사용해야 한다.
get
데이터를 READ, 조회할 때 사용한다.
https://(도메인)/classes/2/students이 URI에 GET으로 들어온 요청이 있다면 2반 학생들을 보려는 요청이구나 하고 짐작할 수 있다.
post
데이터를 Create, 새로운 정보를 추가하는 데 사용한다.
https://(도메인)/classes/2/students위의 도메인이 post 방식으로 들어오게 된다면, 이 반에 새로운 학생이 들어와서 정보를 추가하기 위한 요청일 것이다. post 요청에서는 body에 새 학생의 정보를 실어 보낸다.
학생의 idx는 보통 정보가 추가되면서 생성되기 때문에 post 요청에서는 명기할 필요가 없다.
put, patch
변경돼야 할 경우에는 put, patch 두 가지 방식이 있다. put은 정보가 전체적으로 변경되야할 때 사용되고 patch는 일부만 변경할 때 사용한다. 이 경우에는 URI에 변경할 학생의 idx를 명시해줘야 해당 학생의 정보를 변경할 수 있다. Update 될 새로운 정보들은 역시 body에 실어 보낸다.
https://(도메인)/classes/2/students/14delete
어떤 학생이 학원을 그만두게 되면 delete를 사용한다. 당연히 URI에는 그 학생의 idx를 명기해줘야 한다.
https://(도메인)/classes/2/students/3
결국 HTTP 프로토콜을 HTTP 프로토콜답게 사용하자는 것이 Rest API가 주장하고 있는 바라고 할 수 있다.
HTTP 요청을 보낼 때 어떤 URI에, 어떤 메서드를 사용할지 개발자들 사이에 널리 지켜지는 약속이며, 형식이기 때문에 기술에 구애받지 않는다.
어떤 언어를 사용하든, 앱을 만들든, 웹사이트를 만들든, 거기에 소프트웨어 간 HTTP로 정보를 주고받는 부분이 있다면 이 형식, 규칙을 준수해서 Restful 한 서비스를 만드는 연습을 할 수 있다.
REST, RESTful, REST API
- REST(Representational State Transfer)
클라이언트 ↔ 서버의 통신 방식으로, URI와 HTTP를 이용한 통신 목적의 아키텍처 스타일이다.
- REST API
REST가 적용된 API.
HTTP를 이용해서 기계들이 통신할 때, HTTP가 가지고 있는 기능을 최대한 활용해서 명확하면서 단순하게 통신하기 위한 목적을 가지고 있다.
- RESTful
REST API를 따르는 서버를 RESTful 하다고 표현한다.
Post를 했을 때 Network 탭에서 확인할 수 있는 탭이다.
response에서는 서버가 클라이언트에게 content-type이 application/json 타입이라는 것을 알려주고 있다.
REST API에서 규정하지 않는 것은 client와 server가 어떤 데이터 타입으로 통신할 것인지. 예를 들어, json, xml 어떤 방식을 사용할 것인지는 규정하지 않는다. 대신 resource를 식별할 때는 URI를 통해 구분한다.
또 행위를 할 때는 post, get, delete와 같이 HTTP의 고유한 메서드를 사용한다. 결과를 알려줄 때는 응답 코드(status code)를 정확하게 사용해서 알려준다.
[참고한 References]
https://developer.mozilla.org/ko/docs/Web/HTTP/Methods
https://www.youtube.com/watch?v=PmY3dWcCxXI
https://www.youtube.com/watch?v=SlZwegFgVe4
https://www.youtube.com/watch?v=iOueE9AXDQQ
https://brunch.co.kr/@ogaa2143/30
[다음에 참고할 ref]