2) API에 대해 알아보자

1. API

• Application Programming Interface의 약자

• 다른 어플리케이션들 끼리 소통할 수 있는 규약 같은 것

• 'Web'에 국한되어 사용되지 않고 넓은 범위에서 사용되고 있다.

• Interface(인터페이스) :

  • 다른 사람 혹은 장치와 연동하기 위해 사용하는 '규칙'

2. API와 HTTP

• '범위'의 개념에서 접근하기

  • API가 좀 더 넓은 개념
    • HTML, Hypertext를 주고받는 API가 바로 HTTP(API)
    • HTTP (API) 뒤에는 API라는 단어가 생략되어 있음

• 추상화 레벨에서 해당 규칙이 대상으로 하는 범위의 개념으로 생각하기
  - 추상화 레벨(아래로 내려갈수록 점점 한정된 범위) :

  1) 최상위

  • 인터페이스 (다른 사람 혹은 장치와 연동하기 위해 사용하는 규칙)

  2) 그 아래

  • API (어플리케이션(소프트웨어) 이 다른 사람 혹은 장치와 연동하기 위해 사용하는 규칙)

  3) 그 그 아래

  • HTTP (Hypertext 문서)를 어플리케이션(소프트웨어) 이 다른 사람 혹은 장치와 연동하기 위해 사용하는 규칙

  4) 그 그 그 아래
  REST (Hypertext 문서) 를 철저한 규칙/제약사항에 맞추어 어플리케이션(소프트웨어) 이 다른 사람 혹은 장치와 연동하기 위해 사용하는 규칙)

3. 크롤링/스크레이핑과 API 방식의 차이

• 크롤링/스크레이핑 :
  - 브라우저에서 HTML 태그 이용해 정보 가져온다.
  • 서버측에서 구현하지 않았지만, 클라이언트가 정보를 가져오려하는 기술
  • 정보를 직접 '꺼내'온다/가져온다는 느낌.
  • 클라이언트가 '구현되지 않는 루트'로 가져오는 것이기 때문에, 불안정한 부분 존재.
    EX. NAVER와 NHN의 분리 => URL의 일부분이 NHN이었다가, NAVER로 바뀜 => HTML 태그 바뀌었기 때문에, 크롤링/스크레이핑 시에 클라이언트는 이런 점 하나하나 다 고려해야 정보 가져올 수 있음.
• API 방식 :
  - 서버에 요청해서 직접 가져온다.
  • 서버 측에서 정보를 제공하는 기능을 구현해놓음.
  • 서버에서 허가를 받는 관문을 통과하면, 서버 측에서 구현한 루트로 정보 제공 받는다.
  • 서버의 허가 : API KEY 발급 (OPEN WEATHER, TWITTER...)
  • 클라이언트의 정보 요구를 서버가 받아들여서 정보를 주기 때문에, 정보를 꺼내오는 것이 아니라 '받는' 느낌.
  • 크롤링/스크레이핑 방식에서 신경썼던 부분들 (EX. HTML태그의 변화) 신경쓰지 않아도 된다.