API / HTTP

• API 를 이해하고 사용할 수 있어야 합니다.
• RESTful API 에 대해서 설명할 수 있어야 합니다.
• API 의 데이터를 받아와 데이터베이스에 저장할 수 있어야 합니다.

HTTP 는 크게 요청 (HTTP Request)과 응답 (HTTP Response)

HyperText Transfer Protocol 이라는 약어로 컴퓨터들의 통신 규약 중 하나

하나의 컴퓨터가 다른 컴퓨터와 소통을 하고 싶을 때에 (파일을 받거나 전달하거나 등) 정해진 규칙과

틀을 준수해야 원활한 소통이 가능 ==> 이렇게 정해진 규칙들을 하나의 규약 (protocol)

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜

 

프로토콜 - 용어 사전 | MDN

* CRUD 에 사용되는 HTTP 메소드 ( HTTP Request )

CRUD	HTTP
Create	post
Read	get
Update	put, putch
Delete	delete

• GET : 특정 리소스를 달라고 할 때에 사용됩니다:
  • 예시: 페이지 로딩할 때

 

• POST : 서버 측의 특정 리소스를 저장할 때 사용됩니다.
  • 예시: 회원가입을 할 때에 특정 유저의 정보를 서버에 저장

 

• PUT/PATCH : 서버 측의 특정 리소스를 업데이트 할 때 사용됩니다.
• PUT 은 데이터 전부를 바꿀 때, PATCH 는 부분적으로 변경할 때 사용됩니다.
  • 예시: 사용자 닉넴임 변경

 

• DELETE : 서버 측의 특정 리소스를 삭제할 때 사용됩니다.
  • 예시: 유저 탈퇴

API 를 제작할 때에는 보통 REST 가이드라인을 따라 제작

= API 는 보통 해당 REST 가이드라인을 따라 HTTP 메소드들이 사용

REST 는 REpresentational State of Transfer

World Wide Web (WWW) 와도 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐의 한 형식

중요한 것은 소프트웨어의 아키텍쳐를 어떻게 형성할 지에 대한 가이드라인

총 6개의 가이드라인이 존재하는데 다 따르게 된다면 해당 아키텍쳐를 'RESTful'

전부 따르지 않더라도 큰 의미에서 'REST API' 라고 부른다

---

6개의 가이드라인

클라이언트-서버 – 사용자 인터페이스 문제를 데이터 스토리지 문제와 분리하여 여러 플랫폼에서 사용자 인터페이스의 이식성을 개선하고 서버 구성 요소를 단순화하여 확장성을 개선합니다.

 

Stateless – 클라이언트에서 서버로의 각 요청에는 요청을 이해하는 데 필요한 모든 정보가 포함되어야 하며 서버에 저장된 컨텍스트를 이용할 수 없습니다. 따라서 세션 상태는 전적으로 클라이언트에 유지됩니다.

 

캐시 가능 – 캐시 제약 조건은 요청에 대한 응답 내의 데이터에 암시적 또는 명시적으로 캐시 가능 또는 캐시 불가능으로 레이블이 지정되어야 합니다. 응답을 캐시할 수 있는 경우 클라이언트 캐시에는 해당 응답 데이터를 나중에 동일한 요청에 재사용할 수 있는 권한이 부여됩니다.

 

균일한 인터페이스 – 소프트웨어 엔지니어링 원리를 컴포넌트 인터페이스에 적용하여 전체 시스템 아키텍처를 단순화하고 상호 작용의 가시성을 향상시킵니다. 균일한 인터페이스를 얻으려면 구성 요소의 동작을 안내하는 여러 아키텍처 제약 조건이 필요합니다. REST는 네 가지 인터페이스 제약 조건으로 정의됩니다. 리소스 식별; 표현을 통한 자원 조작; 자기 설명 메시지; 애플리케이션 상태의 엔진으로서의 하이퍼미디어.

 

계층화된 시스템 – 계층화된 시스템 스타일을 사용하면 각 구성 요소가 상호 작용하는 직접 계층 너머를 "볼" 수 없도록 구성 요소 동작을 제한하여 아키텍처가 계층적 계층으로 구성될 수 있습니다.

 

주문형 코드(선택 사항) – REST를 사용하면 애플릿 또는 스크립트 형태의 코드를 다운로드하고 실행하여 클라이언트 기능을 확장할 수 있습니다. 이는 사전 구현해야 하는 기능의 수를 줄여 클라이언트를 단순화합니다.

---

한 유저가 API 를 사용할 때 HTTP 의 GET 으로 이미지를 받아왔는데 다른 API 서버로 가니까 POST 를

보내야 하는 상황에서는 각 API 활용법이 다르고 사용할 때마다 개별적으로 알고 있어야 합니다.

==> REST 아키텍쳐는 HTTP 를 사용할 때 일종의 가이드라인을 제시해서 웹 API 의 혼란 속에 질서를 세우는 것

 

REST API 활용 예시 - GET

1. HTTP GET http://www.appdomain.com/users

2. HTTP GET http://www.appdomain.com/users?size=20&page=5

3. HTTP GET http://www.appdomain.com/users/123

4. HTTP GET http://www.appdomain.com/users/123/address

 

1번 같은 경우에는 /users 로 끝나고 서버에 기록된 유저들을 가져올 거라고 예상할 수 있습니다.

 

2번 같은 경우에는 마찬가지로 유저를 가지고 오지만 추가 쿼리 파라미터 (? 뒤에 오는 항목들)를

통해 페이지와 개수를 정해주고 있습니다.

 

3번 같은 경우에는 유저를 가지고 오지만 유저 목록 중에서 123 에 일치하는 유저를 가지고

올 거라는 예상을 할 수 있습니다.

 

4번 같은 경우에는 3번의 유저 정보에서 address 정보만 가지고 올 거라는 예상을 할 수 있습니다.

/devices
/devices/{id}
 
/configurations
/configurations/{id}
 
/devices/{id}/configurations
/devices/{id}/configurations/{id}

HTTP Response

클라이언트 측에서 요청을 보내게 되는 경우 서버 측에서도 다양한 응답을 보내게된다.

각 응답은 기본적으로 상태 코드 (Status Code) 라는 것을 가지고 있고 HTTP 요청에 대한 상태가 어떤지 알려주는 것

• 100 번대 : 정보 응답
• 200 번대 : 성공 응답 

• 200 (OK)
• 201 (Created)
• 202 (Accepted)
• 204 (No Content)

• 300 번대 : 리다이렉션 메시지 (Moved Permanently)
• 400 번대 : 클라이언트 에러 응답
• 500 번대 : 서버 에러 응답

응답을 보낼 때에는 상태 코드도 있지만 때에 따라 문자열이나 JSON 등을 이용해서

데이터를 함께 실어서 보내기도 합니다.

'Request Method': 이전에 봤던 HTTP 요청 메소드 중 GET, 리소스를 가져온다는 뜻인 메소드를 사용하고 있습니다.

 

'Status Code' : 200 이라는 숫자 앞에 초록색 불이 들어왔습니다. 200 은 'OK', 성공했다는 뜻입니다.

여기에서는 GET 요청이 성공적이었다는 뜻이 됩니다.

 

'Request URL' : 누가 요청을 하고 있는지를 담고 있습니다.

 

'Remote Address' : 어느 리모트 서버에 요청을 하고 있는지 알려주고 있습니다.

현재는 157.245.183.96 의 443 포트에 요청을 보내고 있습니다.

 

'Referrer Policy' : 요청을 보내는 곳이 당사자인지, 타 웹사이트에서 연결된 건지 등 알려줍니다.

현재는 'no-referrer' 로 현 웹사이트에서 보내고 있습니다.

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

---

API 란? Application Programming Interface

프로그램들이 소통할 수 있는 인터페이스

Client

메뉴판을 사전에 약속된 규칙들

클라이언트가 어떤 요청을 하던 간에 이를 다루게 되는 음식점은 요청에 대한 여러가지 답변이 있을 수 있다.

물을 손님이 떠와야 한다고 알려줄 수도 있고 추천 메뉴와 같은 요청은 들어줄 수도 있습니다.

메뉴에 없는 음식이라면 들어줄 수가 없다고 답변할 수도 있죠

API

client가 메뉴를 보고 요청을 할 수 있도록 중간다리 역할을 해주는 웨이터가 바로 API

웨이터는 손님이 하는 요청들을 처리해주는 역할도 하기 때문에 요청에 따라 어떻게 대응해야 하는지 알고

그렇다고 웨이터가 원하는 대로 대응하지는 않고 음식점에서 정한 대응 방식을 따른다.

즉, API 는 원하는 것을 전달하는 것이 아닌 서버의 답을 전달

Server

실질적으로 요청을 처리해주게 됩니다. 요청을 처리할 때에는 해당 요청이 성공했는지 실패했는지 혹은 다른 상태인지를 알려주는 것도 포함됩니다. 그리고 데이터베이스와도 연결되어 있기 때문에

최종적으로 클라이언트가 원하는 데이터를 넘겨줄 수 있어야 합니다.

예를 들면 손님이 햄버거를 주문했는데 피클을 빼달라고 요청을 하게 되면 웨이터가 직접 피클을 빼주지 않는다.

API 응답

사실 서버에서 응답을 보낼 때에 규칙처럼 정해진 형식은 없습니다. 경우와 상황에 따라 다르겠죠.

그러나 보통 접하게 될 수 있는 응답은 JSON 형식일 가능성이 높습니다.

파이썬의 딕셔너리처럼 키-값 (Key - Value) 로 묶여져 있는 구조

{
  "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"
        }
      }
    }
  }
}

파이썬 호환성

몇몇 API 들은 파이썬을 위한 패키지가 있다. 패키지가 없는 경우가 많기 때문에 

데이터를 받아와 파이썬에서 작업할 수 있는 형태로 변경해주는 과정을 거침

 

import requests import json

API_URL = 'https://api.openweathermap.org/data/2.5/weatherq=Seoul&appid=45bc66d3dc908361847111b442dc253b'

 

raw_data = requests.get(API_URL)

parsed_data = json.loads(raw_data.text)

print(parsed_data)

---

HTTP != REST API 엄격하게는 다르지만 ( 비슷하게 사용 )

 REST 아키텍처 스타일에서 데이터와 기능은 리소스로 간주되며 URI(Uniform Resource Identifier)를

사용하여 액세스됩니다. 리소스는 간단하고 잘 정의된 작업 집합을 사용하여 작동됩니다. 

 

클라이언트와 서버는 표준화된 인터페이스와 프로토콜(일반적으로 HTTP)을 사용하여 리소스 표현을 교환합니다.

 

HTTP API는 HTTP를 사용해서 서로 정해둔 스펙으로 데이터를 주고 받으며 통신하는 것

그래서 상당히 넓은 의미로 사용된다.

 

반면에 REST API는 HTTP API에 여러가지 제약 조건이 추가(6개 원칙)

이런 제약 조건을 완벽하게 지키면서 개발하는 것을 RESTful API

실무에서 이런 방법으로 개발하는 것은 현실적으로 어렵고, 또 추가 개발 비용대비 효과가 있는 것도 아니다.

 

해당 조건을 지키지 않아도 REST API라고 하기 때문에, HTTP API나 REST API를 거의 같은 의미로 사용하고 있다.