API

Application Programming Interface : 프로그램이 소통할 수 있는 인터페이스
프로그램을 다룰 수 있는 조작 방법이나 메뉴얼
기존에 존재하는 프로그램과 어떻게 소통할 수 있는지 알려주는 인터페이스
프로그램 간 소통 -> 사람이 받아온 데이터를 처리하기 힘들다.

API 예시

클라이언트 & API

손님 = 클라이언트
메뉴 = API
메뉴판 = 사전에 약속된 규칙
손님은 메뉴를 확인 후 주문, 웨이터는 주만 내용을 요리사에게 전달, 요리사는 음식을 조리
메뉴는 단지 문서인데, API도 유사하며, 실체가 없다.
다양한 문서에서 개념적인 부분을 생략하고 API를 서비스나 결과물처럼 명시
음식을 받아야 실제 내용을 확인할 수 있듯 API 역시 결과 혹은 Return Value를 받아야 실체를 확인할 수 있다.

API Server

손님(클라이언트)가 요청하는 역할이라면, 요청할 수 있도록 중간다리 역할의 웨이터 = API Server
웨이터는 주문을 받는 것과 전달하는 역할, 요청을 처리하는 역할 -> 요청에 따라 어떻게 대응해야 하는지 알고 있다.
API Server : 원하는 것을 전달하는 것이 아닌 Service Server의 결과를 전달
웨이터가 없다면 불편해도 손님이 주방에서 직접 주문할 수 있듯, API Server가 없어도 클라이언트가 Service Server에서 직접 소통할 수 있다.
웨이터가 없는 만큼 손님과 주방에서 해야 할 부담이 증가 or 바쁜 음식점의 경우 웨이터의 수를 늘린다.
API Server 입장에서 부담을 처리하는 방식 중 하나로 로드 밸런싱이 있다.
- 로드 밸런싱 : 컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋 이상의 CPU 혹은 RAM와 같은 컴퓨터 자원들에 작업을 나누는 것을 의미

Service Server

클라이언트의 요청에 대한 대응을 해야 하며 실질적으로 요청을 처리
요청을 처리할 때 해당 요청이 성공했는지 실패했는지 혹은 다른 상태인지 알려주는 것도 포함
DB와도 연결되어있기 때문에 최종적으로 클라이언트가 원하는 데이터를 넘겨준다.

API 응답

보통 접하게 되는 응답은 JSON 형식일 가능성이 크다.

JSON

Javascript Object Notation : JS에서 Object를 표기하는 방식
Python의 dict형태

{
  "glossary":{
    "title":"example glossary",
    "GlossDiv":{
      "title":"S",
      "GlossList":{
        "GlossEntry":{
          "ID":"SGML",
          "SortAs":"SGML",
          "GlossTerm":"Standard Generalized Markup Language",
          "Acronym":"SGML",
          "Abbrev":"ISO 8879:1986",
          "GlossDef":{
            "para":"A meta-markup language, used to create markup languages such as DocBook.",
            "GlossSeeAlso":[
              "GML",
              "XML"
            ]
          },
          "GlossSee":"markup"
        }
      }
    }
  }
}

HTTP API

HyperText Trancfer Protocol : 컴퓨터의 통신 규약 중 하나
- cf. 메일 규약 POP3, SMTP, IMAP
HTTP는 웹에서 통신할 때 사용되는 규약

HTTP Request

한 컴퓨터가 다른 컴퓨터에 리소스 요청을 보낼 때 사용되는 말
요청을 하는 컴퓨터는 클라이언트, 받는 컴퓨터는 서버
HTTP의 요청 또한 클라리언트의 목적에 따라 다르게 분류

CRUD에 사용되는 HTTP 메소드

GET : 특정 리소스를 달라고 할 때 사용
- cf. 페이지 로딩
POST : 서버 측의 리소스를 저장할 때 사용
- cf. 회원가입할 때 특정 유저의 정보를 서버에 저장
PUT/PATCH : 서버 측의 특정 리소스를 업데이트할 때 사용
- PUT : 데이터 전부를 바꿀 때
- PATCH : 부분적으로 변경할 때
- cf. 사용자 닉네임 변경
DELETE : 서버 측의 특정 리소스를 삭제할 때 사용
- cf. 유저 탈퇴
다양한 HTTP 요청 메소드 확인 : MDN HTTP Request Methods
어느 HTTP 메소드인지에 따라 제한이 있다.
- GET이나 DELETE의 경우 주소에만 데이터를 담아 넘길 수 있다.
API를 제작할 때 보통 REST 가이드라인을 따라 제작되며 보통 해당 REST 가이드라인을 따라 HTTP 메소드가 사용된다.

HTTP Response

클라이언트 측에서 요청을 보내게 되는 경우 서버 측에서도 다양한 응답을 보내게 되는데 각 응답은 기본적으로 상태코드를 가지고 있다.
상태코드 분류
- 100 번대 : 정보 응답
- 200 번대 : 성공 응답
- 300 번대 : 리다이렉션 메시지
- 400 번대 : 클라이언트 에러 응답
- 500 번대 : 서버 에러 응답
문자열이나 JSON을 이용해 데이터를 함께 실어서 보내기도 한다.

HTTP 예시

개발자 도구 네트워크 탭에서 실제로 보내지는 HTTP 요청과 응답을 볼 수 있다.
- 크롬 브라우저 네트워크 탭 여는 방법

Request Method: 이전에 봤던 HTTP 요청 메소드 중 GET, 리소스를 가져온다는 뜻인 메소드를 사용
Status Code : 200이라는 숫자 앞에 초록색 불이 들어왔다. 200 은 ‘OK’, GET 요청이 성공적이었다는 뜻
Request URL : 누가 요청을 하고 있는지
Remote Address : 어느 리모트 서버에 요청하고 있는지. 현재는 157.245.183.96 의 443 포트에 요청을 보내고 있다.
Referrer Policy : 요청을 보내는 곳이 당사자인지, 타 웹사이트에서 연결된 건지. 현재는 ‘no-referrer’로 현 웹사이트에서 보내고 있다.

REST API

웹 앱은 API를 제공해야 하는데, 다른 사람이 활용하기에도 수월하고 다음에 본인이 사용할 때도 활용법을 일일이 기억할 필요를 줄이기 위해 코드를 신경 써야 한다.

REpresentatioanal State of Trancfer

REST 위키백과
World Wide Web(WWW)와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐의 한 형식
소프트웨어의 아키텍쳐를 어떻게 형성할지에 대한 가이드라인
총 6개의 가이드라인이 존재하는데 다 따르게 된다면 해당 아키텍쳐를 ‘RESTful’이라고 부른다.
API가 REST의 가이드라인을 다 따르면 해당 API를 RESTful API라고 부른다.
몇 개의 REST 아키텍쳐 제약을 따르게 될 때 넓은 의미에서 봤을 때 REST 아키텍쳐와 비슷한 행동을 보이기 때문에 REST API로 불린다.
REST API 튜토리얼

REST와 HTTP

HTTP Request

REST 아키텍처는 HTTP를 사용할 때 특정 가이드라인을 제시
서버에서부터 요청할 때, HTTP의 GET이나 POST 혹은 다른 요청을 보내도 소통에 문제가 발생하지 않는다.
하지만 한 유저가 API를 사용할 때 HTTP의 GET으로 이미지를 받아왔는데, 다른 API 서버에서는 POST를 보내야 하는 상황에서는 각 API 활용법이 다르고 사용할 때마다 개별적으로 알고 있어야 한다. -> 인터넷에는 셀 수 없을 만큼의 API가 존재하고 제멋대로 작성되어 있다면 사용하는 유저는 피곤하다.
REST 아키텍처는 HTTP를 사용할 때 일종의 가이드라인을 제시해서 웹 API의 혼란 속에 질서를 세운다. -> 모든 API가 다 따를 필요는 없다.
REST API HTTP 메소드
- GET : 데이터를 조회
- POST : 데이터를 생성
- PATCH : 데이터를 업데이트 (일부 변경)
- PUT : 데이터를 업데이트 (전체 변경)
- DELETE : 데이터 삭제
API에서는 일종의 컨벤션으로 해당 HTTP 메소드마다 통용되는 의미가 있다.

REST API 예시 - GET

GET은 REST에서 정보나 리소스를 갖고 올 때만 사용하라고 제시 -> 서버에 기록된 데이터나 리소스를 변경할 때 사용하면 안 된다.
기존 리소스에 대한 변경을 하지 않기 때문에 안전한 메소드
서버의 리소스가 변경되지 않았다는 가정하에 매번 동일한 결과를 나타내야 한다.
GET 요청 예시
- HTTP GET http://www.appdomain.com/users
- HTTP GET http://www.appdomain.com/users?size=20&page=5
- HTTP GET http://www.appdomain.com/users/123
- HTTP GET http://www.appdomain.com/users/123/address

HTTP Response

REST에서 주로 사용되는 HTTP 상태코드
대표적인 상태코드
- 200 (OK)
- 201 (Created)
- 202 (Accepted)
- 204 (No Content)
- 301 (Moved Permanently)

openweather API

회원가입
Current Weather Data API doc 확인

API call 복사

API Key 확인

주소창에서 확인 -> error

메일 인증 후 최대 2시간 기다려야한다.

전시 확인

Python 호환

import requests
import json

API_URL = 'https://api.openweathermap.org/data/2.5/weather?q=Seoul&appid=16d025a15855d89923b7f0596620b840'

raw_data = requests.get(API_URL)

parsed_data = json.loads(raw_data.text)

print(parsed_data)
'''
{
   "coord":{
      "lon":126.9778,
      "lat":37.5683
   },
   "weather":[
      {
         "id":801,
         "main":"Clouds",
         "description":"few clouds",
         "icon":"02d"
      }
   ],
   "base":"stations",
   "main":{
      "temp":297.94,
      "feels_like":298.12,
      "temp_min":297.81,
      "temp_max":299.38,
      "pressure":1004,
      "humidity":63
   },
   "visibility":10000,
   "wind":{
      "speed":5.66,
      "deg":240
   },
   "clouds":{
      "all":20
   },
   "dt":1632213819,
   "sys":{
      "type":1,
      "id":8105,
      "country":"KR",
      "sunrise":1632172726,
      "sunset":1632216711
   },
   "timezone":32400,
   "id":1835848,
   "name":"Seoul",
   "cod":200
}
'''

[DE] API

API

API 예시

클라이언트 & API

API Server

Service Server

API 응답

JSON

HTTP API

HTTP Request

CRUD에 사용되는 HTTP 메소드

HTTP Response

HTTP 예시

REST API

REpresentatioanal State of Trancfer

REST와 HTTP

HTTP Request

REST API 예시 - GET

HTTP Response

openweather API

Reference