개요

REST API는 정보들이 주고받아지는데 있어서 개발자들 사이에 널리 쓰이는 일종의 형식. 우체국에 가면 작성해야 하는 폼처럼 어떤 기술이나 제품이 아닌 형식이기 때문에 어떤 프로그래밍 언어, 프레임워크, OS를 사용하든 이 폼에 맞춰서 기능을 개발하면됨.

API란

어떤 기계를 만들면, 사용자가 그 기능들을 전부 활용할 수 있도록 제어장치를 마련해야 함. TV-리모콘, 자판기-버튼, 컴퓨터-키보드마우스가 이에 해당하는데 이를 Interface라고 함. 기계와 인간간의 소통창구임. 사용자가 명령을 넣는것 뿐 아니라 그 결과와 정보들을 받아오기 위한 모니터도 이에 속함. 소프트웨어에서는 컴퓨터나 스마트폰에서 사용자들이 프로그램이나 사이트, 앱을 원하는대로 제어하고 정보를 볼 수 있도록 버튼, 스크롤바, 슬라이더, 브라우저창 등 소프트웨어적 장치들이 마련돼있음. 소프트웨어와 인간의 소통을 위한 User Interface임.

하지만 IT세계에서는 우리눈에 직접 보이지 않는 영역이 더 많음. 기계-기계, 소프트웨어-소프트웨어 간에서도 수많은 요청과 정보교환이 이뤄지고 있음. 이들 사이에도 소통할 수 있는 창구가 필요함. 기상정보가 관리되는 기상청서버가 있고, 포털이나 기타 날씨에 관련된 서비스를 제공하는 다양한 웹사이트들, 앱들이 이 기상청서버로부터 실시간으로 날씨정보를 요청해서 받아가게됨.

미리 작성된 소프트웨어를 통해서 이 기상청 서버와 이 서버들 또는 앱들 사이에 정보들이 요청되고 전송되는 것임. 이 기상청서버에게 정보들을 요청하는 지정된 형식이 있어야함. date에 날짜, place에 지역, which에 조회할 내용을 표시해서 이 주소로 정보를 요청하면 "17degree"와 같은 형태의 답이 올거라는 공개된 메뉴얼이 있다면 누구든 이를 활용해서 기상청 정보를 활용하는 소프트웨어를 만들 수 있을 것임. 이처럼 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청, 명령을 받을 수 있는 수단을 API(Application Programming Interface)이라고함.

꼭 네트워크 상에서만 API가 있는것은 아님. 로컬 프로그램인 브라우저는 Web API를 통해 자바스크립트로부터 특정동작들을 지시받기도함. 윈도우에는 개발자들이 프로그램을 개발할 때 시스템이나 하드웨어에 대한 깊은 지식 없이도 지정된 명령어로 윈도우에서 동작을 수행하도록 소프트웨어를 짤 수 있는 Windows API를 제공함.

REST API

프론트엔드 웹에서 서버에 데이터를 요청하거나, 배달앱에서 서버에 주문을 넣는 등의 서비스들에서 오늘날 널리 사용되는 것이 REST형식의 API임. 과거 복잡한 형식의 SOAP을 대체한 것. REST의 가장 중요한 특성은 각 요청이 어떤 동작이나 정보를 위핸 것인지를 그 요청의 모습 자체로 추론이 가능하다는것.

기능구현만 중요하다면 REST를 따질필요 없이 동작하게 하도록 하면됨. 어떤 학원의 반과 학생들에 대한 API를 만들때, '주소끝에 1을 붙이면 반들의 리스트, hello를 붙이면 학생들 리스트, hyot-hong을 붙이면 담아진 내용대로 학생 정보 수정'과 같은 식으로 짜도 이에 맞춰 요청을 보내는 앱을 만들면 서비스의 기능 자체에는 아무런 문제가 없을 것임. 하지만 개발자들은 협업을 함. 작업을 이어받거나, 이 API를 통해 다른 제품을 만들 개발자들은 업무에 고통을 겪게 될것임.

RESTful하게 만든 API는 요청을 보내는 주소만으로도 대략적인 요청의 의미를 파악할 수 있음.

학원DB에 정보를 보내달라는 요청을 할 때 주소에 classes가 붙는다면 학원의 반들 목록을 받아오는 요청일 것임.

index, 고유번호가 따라붙으면 보통 그 반들 중 인덱스 번호가 이 숫자인 반의 정보가 옴.

그 뒤에 students를 붙이면 이 반에 해당하는 학생들의 정보가 옴.

그 뒤에 인덱스번호를 붙이면 이 인덱스 번호를 가진 학생들의 정보가 옴.

혹은 sex=male과 같은 조건을 붙여 남학생들의 정보만 받아올 수도 있음.

page=2&count=10과같이 입력하면 한 페이지에 10명씩 받아오는 요청의 표현이 가능.

이렇게 자원을 구조와 함께 나타내는 구분자를 URI라고 함.

그러나 이런 조회작업 뿐 아니라, 정보를 새로 넣거나, 수정하거나 삭제하는 작업도 필요함. 이들을 CRUD라고 함. Create(생성), Read(조회), Upadte(수정), Delete(삭제). 서버에 REST API로 요청을 보낼 때는 HTTP란 규약에 따라 신호를 전송함. 우체국에 가면 다양한 방식이 있듯이 HTTP로 요청을 보낼 때도 여러 메서드가 있음. REST API에서는 GET, POST, PUT, DELETE(, PATCH)를 사용함.

소포가 편지보다 많이 담을 수 있듯 POST, PUT, PATCH에는 body란 주머니가 있어서 정보들을 GET이나 DELETE보다 많고, 안전하게 감춰서 전송할 수 있음. 이것들의 기능이 특정 용도에 제한되어 있지는 않음. 예를들어 POST하나만으로도 CRUD를 구현가능함. 하지만 누구든 각 요청의 의도를 쉽게 파악할 수 있도록 RESTful하게 API를 만들기 위해서는 이들의 목적에 따라 구분해서 사용해야 함.

GET은 데이터를 Read할 때 사용. 이와같은 URI에 GET으로 보내는 요청이 있다면 일반적으로 2반의 학생들을 보는 요청임을 짐작할 수 있음.

POST는 데이터를 Create할 때 사용. 2반에 새 학생이 들어와서 정보를 추가하려면 위와같은 URI를 짜고 POST요청을 작성해서 body에 새 학생의 정보를 실어보냄. 학생의 idx는 보통 정보가 추가되면서 생성되기 떄문에 POST요청에서 이를 명기할 필요가 없음.

idx 14를 가진 학생의 정보들이 변경됐을 경우는 변경할 학생의 idx까지 명기한 다음 PUT 또는 PATCH를 사용해서 변경(Update)될 새 정보들을 body에 실어서 보냄.

PUT과 PATCH의 사용은 쓰는 곳마다 다르고, PUT으로만 사용하는 곳들도 있음. 정석은 PUT은 정보를 통째로 갈아끼울 때, PATCH는 정보 중 일부를 특정 방식으로 변경할 때 사용.

어떤 학생이 학원을 그만두면 DELETE를 사용함. 당연히 URI는 해당 학생의 idx까지 표시해야 할 것.

POST나 PUT중 하나로도, 용량이 적고 중요도가 낮은 정보들은 GET만으로도 4가지 동작의 구현이 가능하겠지만, 구분 가능한 요청을 위해서 URI에 동작을 명기해야 함. 이런 것들을 지양하기 위한 REST의 규칙 중 하나로 URI는 동사가 아닌 명사들로 이뤄져야 한다는 것이 있음. 결국 REST API란 HTTP요청을 보낼 때 어떤 URI에 어떤 메서드를 사용할지 개발자들 사이에 널리 지켜지는 약속임. 형식이기 때문에 기술에 구애받지 않음. 앱을 만들든, 웹사이트를 만들든, 어떤 언어로 만들든 소프트웨어간 HTTP로 정보를 주고받는 부분이 있다면 이 형식을 준수해서 RESTful한 서비스를 만들 수 있음.

참고자료