[N323] TIL 및 회고

Sea Panda·2022년 12월 20일
코드스테이츠
0

부트캠프 TIL

목록 보기
31/46
post-thumbnail

0. 학습목표

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

1. 주요개념

1. API

N314에서 API가 무엇인지 간단히 다루었다. 이번에는 조금 더 상세하게 다루어 보고자 한다.

API란 "Application ProgrammingInterface"의 줄임말로 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성요소가 서로 통신할 수 있게 하는 메커니즘이라고 앞서 정리하였었다. 이 API를 더 이해하기 위해서는 클라이언트와 서버도 같이 이해해야 어떤 방식으로 작동하는지 이해할 수 있다.

위의 사진을 통해서 API의 예시를 들어보면, 음식점에서 손님은 뭔가를 요청하고 있는 클라이언트이고 메뉴는 API이다. 손님은 주방에 들어가서 조리되는 음식을 보고 메뉴를 정하지 않는다. 또한 메뉴판에 없는 음식을 주문할 수도 없다. 메뉴판을 보고 음식을 고를 수 있는 이유는 메뉴판을 통해 어떤 음식이 나올지 어느 정도 예상하고 있기 때문이다. 그렇기 때문에 메뉴판은 손님과 주방 사이의 규칙으로 볼 수도 있다. 만약에 피자를 시켰는데 햄버거가 나온다면 메뉴판은 제 역할을 수행하지 못한 것이고, 손님 입장에서는 원했던 음식이 나오지 않게 되는 것이다.

여기서 중요한 점은 메뉴판(=API)은 단지 문서일 뿐이라는 것이다. 따라서 구체적인 실체가 존재하지 않는다. 하지만 몇몇 문서와 업체에서는 API를 어떤 특정한 서비스나 기능처럼 설명하기도 한다.

여기서 메뉴판의 주문을 주방장이 직접 받아서 요리까지 한다면 효율이 떨어질 것이다. 그래서 주문을 대신 받아 전달해주는 웨이터를 가게에 고용했다고 생각해보자 바로 이 웨이터가 API Server이다. 웨이터가 음식 주문을 받고, 조리된 음식을 전달하듯이 API server도 Service Server의 결과를 전달해준다. 즉 클라이언트와 Service server가 조금 더 원할하게 소통할 수 있게 도와준다.

그리고 주방장에 해당하는 Service server는 실제로 클라이언트의 요청에 대한 task를 처리하는 server이다.

API를 통해서 원하는 요리, 즉 데이터를 받으면 대체로 JSON형식 반환받는다. 대체로 그렇다는 것이지 API를 통한 서버의 응답에는 정해진 형식이 없으며 경우와 상황에 따라 다르다. 하지만 실제로 많이 사용하는 Web API는 앞서 말한 JSON형식을 가장 많이 사용한다.

💡 JSON??
JSON(Javascript Object Notation)는 Javascript에서 Object를 표기하는 방식을 의미한다.

얼핏 보기에는 파이썬이 "Dictionary"를 표기하는 방식과도 비슷하게 생겼다. 실제로도 아래의 JSON예시를 그대로 파이썬 변수값으로 입력해도 문제가 없다. 그대로 가져다 사용할 수 있는 셈이다. JSON은 다른 프로그래밍에서도 사용되고 있을 정도로 표준처럼 자리 잡았다. 그렇기 때문에 Javascript에 국한되어 있지 않고 널리 사용된다.

또한 JSON을 이용한 구조는 사람들도 나름 쉽게 읽고 이해할 수 있고 어플리케이션에서도 쉽게 이해할 수 있는 장점이 있다.

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

2. HTTP API

HTTP는 HyperText Transfer Protocol이라는 약어로 컴퓨터들의 기술적인(알고리즘, 데이터 형식, 계층구조 등..) 통신규약(protocol) 중 하나이다. 하나의 컴퓨터가 다른 컴퓨터와 파일을 받거나 전송하거나 하는 등의 소통을 하고 싶을 때에 정해진 규칙과 틀을 준수해야 원활한 소통이 가능하다.

예를 들어 이메일을 주고 받을 때에는 이메일 사이트로 로그인해서 받은 편지함을 보면 되지만 실제로 받아야 하는 메일을 받아야 하는 이메일 주소로 보낼 수 있도록 해주는 규약들이 있다. POP3, SMTP, IMAP등이 그러한 규약들이다.

HTTP는 웹에서 통신할 때 사용되는 규약이다. 따라서 모든 컴퓨터는 웹에서는 HTTP를 사용하여 소통한다. HTTP를 사용하게 된다면 웹과 관련된 작업을 한다는 것을 표현하는 것이기도 하다. 위의 그림에서 나오듯이 HTTP를 통한 소통은 크게 요청(HTTP Request)과 응답(HTTP Response)로 나눠져있다.

HTTP Request
한 컴퓨터가 다른 컴퓨터에 리소스 요청을 보낼 때 사용되는 말이다. 보통 요청을 하는 컴퓨터는 클라이언트라 부르고 요청을 받는 컴퓨터는 서버라고 부른다. 이러한 요청을 보낼 때 사용하는 것들을 HTTP 요청 메소드라고 하며, 다양한 메서드들을 MDN HTTP Request Methods에서 확인 가능하다.

다양한 메서드들 중에서 데이터를 다룰 때 큰 틀의 기준이 되는 4가지 요청인 CRUD에 해당하는 메소드는 다음과 같다.

이러한 요청들을 특정 방법으로 사용하도록 정해진 것은 아니다. DELETE메소드를 사용해 회원가입을 진행할 수 있고 GET으로 업데이트도 할 수 있다. 이렇게 할 수 있는 이유는 클라이언트와 서버가 사전에 약속된 방법만 있다면 작동에는 문제가 없기 때문이다.

물론 어느 HTTP메소드인지에 따라 제한이 있다. GET이나 DELETE와 같은 경우에는 주소에만 데이터를 담아 넘길 수 있다. 복잡한 데이터 형태를 넘기기에는 제한이 많다.

그리고 각각의 CRUD요청은 각각의 주소를 가지게 되고, 클라이언트는 각각의 주소로 요청을 보내게 되는데, 모든 CRUD요청마다 주소가 생기면 주소의 수가 너무 많아져 관리가 어려워지고, 기능이 겹치는 주소가 담긴 API에 버그가 생긴다. 이를 해결하기 위하여 사람들은 CRUD를 하나의 주소로 관리하는 API, RESTful API를 사용하기 시작했다. API를 제작할 때에는 보통 REST가이드라인을 따라 제작된다. 그리고 이 가이드라인을 따라 HTTP메소드들이 사용된다.

HTTP Response
HTTP Request를 보내면 이 요청은 HTTP규약을 통해서 보낸 요청이기 때문에 응답 또한 HTTP규약에 따른 응답을 받게 된다.

클라이언트 측에서 요청을 보내게 되는 경우 서버 측에서도 다양한 응답을 보내게 되고, 각 응답은 기본적으로 상태코드(Status Code)라는 것을 가지고 있다. HTTP요청에 대한 상태가 어떤지 알려주는 것이다. 상태 코드는 총 5개의 종류로 나누게 된다.

💡 HTTP 상태 코드 분류

  • 100번대: 정보응답
  • 200번대: 성공응답
  • 300번대: 리다이렉션 메시지
  • 400번대: 클라이언트 에러 응답
  • 500번대: 서버 에러 응답

이런 응답코드는 웹페이지를 열어 개발자 도구를 연 뒤에 네트워크 탭으로 들어가면 실제로 보내지는 HTTP요청과 응답을 볼 수 있다.

3. RESTful API

REST는 REpresentational State of Transfer의 줄임말이다. 지금 널리 사용되고 있는 World Wide Web(WWW)와도 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐의 한 형식이다. 여기서 중요한 것은 소프트웨어의 아키텍쳐를 어떻게 형성할지에 대한 가이드라인이라는 것이다. 총 6개의 가이드라인이 존재하는데 다 따르게 된다면 해당 아키텍처를 RESTful이라고 부르게 된다.

조금 더 REST에 대해서 간결하게 정리하면 다음과 같다.

  1. HTTP URI를 통해 자원(Resource)을 명시한다. 👉 자원
  2. HTTP Method를 사용하여 👉 자원에 대한 행위
  3. 해당 자원(URI)에 대한 CRUD Operation을 적용한다. 👉 자원에 대한 행위의 내용

REST의 특징으로는 5가지를 들수 있으며 다음과 같다.

  1. Server-Client(서버-클라이언트 구조)
  2. Stateless(무상태)
  3. Cacheable(캐시 처리 가능)
  4. Layered System(계층화)
  5. Uniform Interface(인터페이스 일관성)

REST아키텍처는 HTTP를 사용할 때 특정 가이드라인을 제시한다. 만약 서버에서 이미지를 요청할 때 어떤 서버는 GET을 통해서 이미즈를 전달할 수 있고, 다른 서버는 POST요청을 통해 이미지를 전달할 수 있다고하자. 각 서버의 API가 다르기 때문에 유저는 사용할 때마다 각 서버의 API활용법을 개별적으로 알고 있어야 한다. 만일 서버가 늘어난다면 유저가 알고있어야 할 API는 더 늘어나게 되고 유저들의 피로감은 엄청날 것이다. 그래서 REST아키텍쳐라는 것이 등장하여 HTTP를 사용할 때 일종의 가이드라인을 제시해서 웹 API의 혼란 속에 질서를 세우려고 하는 것이다. 하지만 말 그대로 가이드 라인이기 때문에 모든 API가 따라야 하는 것은 아니다. 보통 RESTful API를 작성했다고 하면 HTTP 메소드를 다음과 같이 사용한다.

  • GET: 데이터를 조회
  • POST: 데이터를 생성
  • PATCH: 데이터를 업데이트(일부 변경)
  • PUT: 데이터를 업데이트(전체 변경)
  • DELETE: 데이터 삭제

2. 회고

RESTful API는 사실 아직 잘 이해는 못했다. 나중에 좀 더 찾아보자.



profile
Sea Panda
이전 포스트

[N322] TIL 및 회고

다음 포스트

[N324] TIL 및 회고

0개의 댓글