API란 Application Programming Interface의 약자로, 애플리케이션 프로그램의 규약을 의미합니다. 이 규약은 프로그램이 어떠한 형태의 **요청(메시지)**을 받아 어떠한 형태의 응답를 반환하는 지에 대한 규칙의 나열입니다.
프론트엔드 개발자들은 백엔드 서버가 제공하는 API를 세부적인 구현 내용을 모르더라도 사용할 수 있습니다. 여기서 백엔드 서버는 마치 블랙박스처럼 작동합니다. 프론트엔드는 백엔드의 구현이 어떻게 되는지에 대해서 관심이 없습니다. 그저 주어진 API에 대한 올바른 결과만 내놓으면 그만입니다. 심지어는 백엔드의 구현이 되어있지 않더라도, 프론트엔드 개발자들은 백엔드 개발을 기다릴 필요 없이 주어진 API에 맞게 구현을 해놓으면 그만입니다.
API는 프로젝트의 초반에 설계되어 프론트엔드와 백엔드 개발의 길라잡이의 역할을 합니다. 프론트엔드는 API를 호출하도록 프로그래밍을 하고, 백엔드는 API를 구현합니다. 그렇기에 초기에 안정적이고 변화 가능성이 적으면서 효과적인 API를 설계하는 것이 중요합니다. 이러한 관점에서 등장한 API를 설계하는 방식이 REST API입니다. REST API는 HTTP 의 특성을 최대로 살리면서도 변경가능성이 적은 API spec을 제공합니다.
결국 API를 설계하고 나면 이를 관리할 수 있는 문서가 필요합니다. API 문서는 종이문서나 엑셀 문서와 같이 낮은 수준의 편의도를 가진 도구로 제공될 수 있으며, API 문서 자동생성 및 수정 기능이 있는 높은 수준의 편의도를 가진 도구로 제공될 수도 있습니다. API 문서를 효과적으로 생성하고 관리하기 위한 도구에는 GitBook, Postman, Swagger 등이 있습니다.
8주차에서는 REST API 의 특징에 대해서 알아보고, 스프링부트와 Swagger를 연동하여 API 문서를 자동으로 생성 및 관리하는 방법에 대해서 알아보겠습니다.
REST란 Representational State Transfer 의 약자로 웹을 이용한 HTTP 통신에서의 제약 조건들을 정의하는 소프트웨어 아키텍처 스타일입니다. REST 는 2000년도에 로이 필딩의 박사학위 논문에서 최초로 소개되었습니다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹과 HTTP의 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 합니다.
REST API는 HTTP를 사용할 때 자원Resource, 행위Method와 표현Representation ****을 기준으로 API를 설계합니다.
여기서 자원이란 웹 애플리케이션에서 다뤄지는 개체들을 의미합니다. 인스타그램으로 예를 들자면 사용자, 글, 스토리, 댓글, 그리고 이들 사이에서 생기는 연관개체들이 있습니다.
행위란 자원을 생성하고, 읽고, 수정하고, 삭제하는 것(CRUD)을 의미합니다.
표현이란 서버가 클라이언트에게 전달하는 내용의 형식으로, 일반적으로 JSON, XML, HTML 등의 형식을 갖습니다.