API(Application Programming Interface)란 애플리케이션 간의 상호 작용을 가능하게 하는 규약 또는 인테페이스
예시1)
사람 - 자판기 버튼 - 자판기
자판기 버튼이 하나의 API가 됨.
콜라 버튼을 누르면 콜라, 사이다 버튼을 누르면 사이다가 나오는 것은 각 버튼에 따라 반환될 음료를 미리 약속했기 때문.
예시2)
식당 손님 - 종업원 - 요리사
종업원이 하나의 API가 됨.
식당 손님이 메뉴판을 보고 종업원에게 주문, (API 호출)
종업원이 주방장에게 메뉴 전달, (Request 전달)
주방장는 메뉴를 완성해서 종업원에게 전달, (DB, 비즈니스 로직 등)
종업원이 식당 손님에게 메뉴 서빙 (Response 전달)
예시3) (API를 사용하지 않았을 경우)
식당 손님 - 주방장
만약 식당 손님이 주방장에게 먹고 싶은 음식을 바로 요청.
식당은 중식당인데 메뉴를 보지도 않고 스파게티를 주문한다면??
=>
API는 미리 정해둔 규격에 맞춰진 요청만 받을 수 있도록 하는 것이다. 이렇게 한다면 종업원(API)을 통해 요청(Request)과 응답(Response)의 규격을 통일할 수 있고, 허가된 데이터에만 접근을 허용할 수 있다.
REST API(Representational State Transfer API)
즉 url이면 uri이기도 함.
예시)
https://example.io
https://example.io 라는 서버를 나타내기 때문에 URL이면서 URI이다.
https://example.io/images
https://example.io 서버의 images라는 네트워크 상의 자원의 위치를 의미하기 때문에 URL이면서 URI이다.
https://example.io/images/dog.jpeg
https://example.io 서버의 images 디렉터리 아래의 dog.jpeg를 가리키므로 URL이면서 URI이다.
https://example.io/user/123
URL은 https://example.io/user 까지고 원하는 정보에 도달하기 위한 식별자 123을 포함하기 때문에 URI이다. 즉, URI이지만 URL은 아니다.
https://example.io/profile?id=11
https://example.io/profile 까지는 URL이지만 원하는 정보에 도달하기 위한 식별자(여기서는 ?id=11)를 포함하기 때문에 URI가 된다. 즉, URI이지만 URL은 아니다
=>
HTTP 프로토콜을 사용하여 웹 서버와 소통할때, HTTP 메소드는 '무엇을 할것인가(동작)'를, URI는 '어디에 있는 것을 할 것인가(대상 자원)'를 나타냄.
예를 들어, 어떤 웹사이트의 특정 페이지를 보고 싶다면, 그 페이지의 URI에 대해 GET 메소드를 사용하는 요청을 보내는 것.
REST API 이어서...
백 (서버)에서 만든 API를 프론트(클라이언트)가 가져다 쓰려면, 어떠한 API가 있고, 해당 API를 쓰기 위해 어떤 양식을 갖춰야 하는지를 알아야 함.
메뉴판에 어떤 메뉴가 있고, 그 메뉴를 주문하려면 무슨 옵션이 있는지 알아야 하는 것과 동일한 맥락
그래서 작성해야하는게 API 명세서이고, Swagger는 API Spec 문서(==API 명세서)를 자동화해주어 간편하게 API문서를 관리하면서 테스트할 수 있게 해줌.