API, Rest API란?

API란? 

Application Programming Interface의 약어이다. 

 

일단 Interface가 무엇인지부터 알아보자.

 

 

Inteface란?

무언가와 상호작용하는 방식을 의미한다. 예를 들면, 집에 있는 TV은 Interface를 가지고 있다. TV를 끄도록 하는 버튼이 있기 때문이다. 그 버튼이 사용자와 텔레비전과 상호작용을 할 수 있도록 하는 Interface이다. 웹 사이트도 Interface를 가지고 있다. 사용자가 웹사이트와 상호작용할 때 누르는 버튼들 이런것들이 다 Interface라고 할 수 있다. Interface는 기본적으로 사용자에게 노출되어있는 버튼이고, 그걸 통해 어플리케이션이나 전자기기 등 무엇이든지 상호작용할 수 있다.

 

또 한가지 예를 들면 아래에 있는 리모콘도 Interface다. 왜냐하면 사용자와 TV가 상호작용할 수 있게 해주기 때문이다. 리모콘에 있는 버튼들을 누르면 어떤일이 일어난다. 즉, 이건 TV를 만든 사람이 노출시킨 기능들이다. 

 

즉, Interface는 무언가(TV)와 무언가(리모콘)를 이용해서 상호작용하는 방식이다. 항상 프로그래밍과 연관 된게 아니다.  전자레인지, 세탁기도 Interface이다.  버튼을 가지고 있고 사용자가 그 버튼을 누르면 특정 명령을 실행한다. 그래서 우리가 API에 대해서 생각할 땐, 우리가 누르는 버튼을 생각하자. 예를 들면, 브라우저에도 많은  API들을 가지고 있다. 즉, 브라우저를 아주 큰 리모콘이라고 생각하면 좋다. 브라우저는 매우 많은 버튼들을 가지고 있다. 지금 이 순간에도 브라우저는 더 많은 버튼들을 만들어내고 있다. 브라우저에 새 API가 추가될 때 마다 개발자들이 좋아하는 이유는 개발자들이 누를 수 있는 버튼을 브라우저가 새로 선보인 것이기 때문이다. 

 

웹사이트도 같다. 아마존, 트위터, 페이스북 같은 모든 웹사이트는 API를 가지고 있다.  그 뜻은 개발자들이 그 사이트와 상호작용을 할 수 있는 버튼들이 있다는 뜻이다. 물론, API는 어플리케이션,서버 웹사이트를 만든 사람이 만들어서 내놓은 것이다. 내놓은 것들로 개발자들은 어플리케이션, 서버, 웹사이트들과 상호작용 할 수 있는것이다!

 

이런것들이 API이다. 우린 주로 프로그래밍할 때 사용하고, 어플리케이션과 상호작용할 때 사용한다. 

 

 

 

 

 

+추가) API란?

서로 다른 프로그램간에 소통할 수 있게 도와주는 통신 규약을 뜻한다. 

 

웹개발시 API란?

- 웹서버와 고객간의 소통방법 (서버에게 요청해서 데이터 가져오는 방법)

- 어떻게 해야 서버랑 통신을 할 수 있을까

 

위 코드들은 API들을 작성한 것이다. 이런 API들을 Rest하게 작성하면 그게 바로 Rest API이다.

 

Rest API에 대해 알아보자.

옛날에는 서버를 만들때 API에 일관성도 없고 막 만들어놓았기 때문에 어려움을 겪었다.

이런 모습을 보고 Roy Fielding이라는 사람이 HTTP 요청 시스템(GET, POST, PUT, DELETE)을 REST 원칙에 의해서 쓰면 인터넷 세상이 평화로워질것이다. 라고 쓴 논문이 있다. 이 논문이 하도 유명해져서 요즘에는 정론으로 받아들아들여졌다.

 

 

REST 원칙 6가지

1. Uniform Interface

인터페이스는 일관성이 있어야한다는 소리이다.

• 하나의 URL로는 하나의 데이터를 가져와야한다. (하나를 가져오기 위한 두개의 URL을 만들지 말자)
• 간결하고 예측가능하게 짜자. (URL 하나를 알면 둘을 알게)
• URL 이름짓기 관습을 잘 따라야한다.

이름짓기 관습이 뭔지는 밑에 가서 더 알아보도록 하자. 

 

(참고) 다른 곳에서 URL 대신 URI 이런 용어를 많이 쓰기도 하는데 URI는 자료를 넘버링하고 분류하고 지칭하는 방법이라 보면 된다. URL과 비슷하지만 조금 더 큰 의미이다. 도서관에서 책 분류할 때 URI에 의해서 분류하기도 한다. 

 

 

2. Client-server 역할 구분하기

고객들은 그냥 URL 하나만 알면 서버에 있는 자료를 갖다쓸 수 있다. 

고객에게 서버역할을 맡기거나 고객에게 DB에 있는 자료를 직접 꺼내라고 하든지 그런 식으로 코드를 짜면 안된다. 

 

3. Stateless

요청들은 각각 독립적으로 처리되어야한다. 

요청1이 성공해야 요청2를 보내주고 그런 식으로 요청간의 의존성이 존재하는 코드를 짜면 안된다. 

다르게 말하면 요청하나 만으로 자료를 가져오기 충분하도록 

요청에 필요한 모든 정보들을 실어 보내는게 좋다는 뜻이다. 

 

4. Cacheable

요청을 통해 보내는 자료들은 캐싱이 가능해야한다.

그리고 캐싱가능하다고 표시하거나 캐싱 기간을 설정해주어야 한다고 한다.

 

캐싱이란?
네이버를 방문하면 크롬 브라우저는 자동으로 자주 사용하는 이미지 파일, CSS 파일 등을 하드에 저장해놓는다. 
별로 바뀔일 없는 네이버 로고나 아이콘 같은거요.
하드에 저장해놓고 네이버 방문할 때 네이버서버에 네이버 로고주세요~라고 요청하지 않고 하드에서 불러온다.
이 행위를 캐싱이라고 한다. 

 

 

5. Layered System

요청처리하는곳, DB에 저장하는곳 이런 여러가지 단계를 거쳐서 요청을 처리해도 된다.

멋있게 말하면 여러개의 레이어를 거쳐서 요청을 처리하게 만들어도 된다고 한다.

 

6. Code on Demand

서버는 고객에게 실제 실행가능한 코드를 전송해줄 수도 있다. 

 

 

 

(Uniform Interface) URL 이름짓기 관습

instagram.com/explore/tags/kpop
instagram.com/explore/tags/food
facebook.com/natgeo/photos
facebook.com/bbc/photos

이 URL들은 페이스북이 매우 잘 만든 API이다. 왜냐하면

facebook.com/bbc/photos 딱봐도 BBC뉴스 페북계정의 사진첩인 느낌이 든다. 한눈에 딱 보인다.

 

- 단어들을 동사보다는 명사 위주로 구성함

- 응용해서 다른 정보들을 쉽게 가져올 수 있을 정도로 일관성 있음 

- 대충 봐도 어떤 정보가 들어올지 예측이 가능함 

 

이외에도 이름을 잘 지을 수 있는 방법은

- 띄어쓰기는 언더바_대신 대시-기호-사용

- 파일 확장자 쓰지 말기 (.html 이런거)

- 하위 문서들을 뜻할 땐 / 기호를 사용함 (하위폴더같은 느낌)

여러가지가 있다. 이것만 잘 지켜주면 Rest full한 멋진 서버 API들이 완성된다. 

 

 

 

 

 

참고 - https://codingapple.com/course-status/