[n331]Intro to API(Application Programming Interface)

■ Key words

  ㆍHTTP(HyperText Transfer Protocol)

  ㆍAPI(Application Programming Interface)

  ㆍRESTful API

  ㆍAPI token

  ㆍ개발자 계정

 

■ 주요내용

  ㆍHTTP(HyperText Transfer Protocol) : 컴퓨터 간 통신 규약

     - HTTP Request : 한 컴퓨터(클라이언트)가 다른 컴퓨터(서버)에 리소스 요청을 보내는 것

     * CRUD(Create, Read, Update, delete)에 사용되는 HTTP 메소드

       · GET : 특정 리소스 수신 요청(i. e. 페이지 로딩)

       · POST : 서버에 특정 리소스를 저장(i. e. 회원가입 시 서버에 유저 정보 저장)

       · PUT(전부)/PATCH(일부) : 서버에 특정 리소스 업데이트(i. e. 닉네임 변경)

       · DELETE : 서버의 특정 리소스 삭제(i. e. 유저 탈퇴)

     - HTTP Response : request에 따른 HTTP 응답 / 상태코드 및 문자열/JSON 등을 이용하여 데이터와 함께 전송 가능

       * 응답의 상태 코드(Status Code)

       · 100번대 : 정보 응답

       · 200번대 : 성공 응답

       · 300번대 : 리다이렉션 메시지

       · 400번대 : 클라이언트 에러 응답

       · 500번대 : 서버 에러 응답

  ㆍAPI(Application Programming Interface) : 프로그램들이 소통할 수 있는 인터페이스. 기 존재하는 프로그램과

    소통방법을 알려주는 인터페이스, 가이드라인, 매뉴얼.

     - Client : 요청하는 주체

     - API : 클라이언트와 서버의 요구 혹은 응답을 상호 전달하는 가교역할을 하는 것.

     - Server : 실질적으로 요청을 처리해주는 주체. 요청에 대한 결과 응답도 포함됨.

     - API Response : 응답을 받아올 수 있는 형식.

       · JSON(Javasript Object Notation) : Javascript에서 object를 표기하는 방식
  ㆍREST(REpresentational State of Transfer) API : an architectural style for an application program interface

     : 대부분의 코드는 작성하는 시간보다 읽히는 시간이 더 많으므로 읽힐 때를 고려하여 API를 작성해야 함

       ⇒ 타인이 보거나 본인이 추후에 이용/수정을 위해 보기 좋게 작성해야 함

     - REST : WWW과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐에 대한 가이드라인.

       * RESTful : REST의 6개 가이드라인에 따라 작성된 아키텍쳐

     - REST와 HTTP : REST Architecture는 HTTP를 사용할 떄 특정 가이드라인을 제시함.

       · HTTP Request : REST는 아키텍쳐 형식이기 때문에 HTTP를 간섭하지 않아 REST 활용 시

         HTTP의 특정 방식을 반드시 사용할 필요는 없음

         → GET : 데이터 조회

         → POST : 데이터 생성

         → PATCH : 데이터 일부 업데이트

         → PUT : 데이터 전체 업데이트

         → DELETE : 데이터 삭제 

       · HTTP Response : 요청에 따라 정형화된 응답이 있음

  ㆍOpenWeather API : OpenWeatherMap API를 활용한 실습

 

■ Session note

  ㆍlikes : 'POST'를 사용하여 좋아요 누른 수, 누른 사람 조회; body - raw - JSON 선택 시 jason  선택 가능
  ㆍtwitter developer portal : project별로 여러 개의 프로그램을 만들 수 있음
  ㆍAPI key, security key, Access key, Acess Token key는 한 번만 보여주기 때문에 꼭 복사해놓기
  ㆍGET 요청을 통해 tap을 만드는 등 다양한 작업을 할 수 있음
  ㆍget user by userid
  ㆍPostman에서는 history에서 내가 했던 작업을 볼 수 있음(불러오기)
  ㆍAPI : 서버와 직접 접근 불가능한 사용자 사이를 연결해주는 것
  ㆍREST API : API를 만들 때 주는 guideline
  ㆍOAuth1.0보다 2.0이 보안을 좀 더 높인 것임
  ㆍHTTP 응답과 실제 서버가 돌아가는 것은 다름

  ㆍpip tweepy
    import tweepy
  ㆍdocs.tweepy.org
  ㆍtweeter에 직접 올리기 / like / DM 기능을 활용하기 위해서 권한을 바꿔야 함 ; post에서 header로 보내기

     (body 아님)
  ㆍ좋아요 삭제 : developer platform - delete
  ㆍExtended Mode(parameter) : 140 글자 넘는(280 글자까지) 트윗 가져오기
  ㆍ관계형 DB의 한계 : 한 곳에 모든 데이터를 담아야 해서 병목현상을 해결할수 없음
     ⇒ MPP를 통해 병을 여러 개를 만들어 원천적으로 병목현상을 해소함
  ㆍprocess는 DB에 요청을 보낸 시간 순서대로 일어남
  ㆍlatency : DB에 요청을 보낸 후 응답이 돌아올 때까지 지연이 있음
     cf> LWW(Last Write Wins) : 제일 마지막 요청이 수정 권한을 가짐
          → 관계형 DB도 점차 NoSQL처럼 병렬형으로 변해가고 있음
              ; HDJS : 카산드라 / HABASE 등 - 여러 수정 요청이 한 번에 들어오면 SQL은 순차적으로 처리하기

               위해 지연이 발생하지만, 병렬형 처리 등을 통해 기다리지 않고 바로바로 처리하는 방향으로 변화 중
  ㆍlog data : NoSQL / 금융, 수강신청, 주식은 SQL

 

■ 주요함수

  ㆍ

 

■ Reference

  ㆍMDN HTTP request methods : https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

HTTP request methods - HTTP | MDN

  ㆍREST : https://ko.wikipedia.org/wiki/REST

REST - 위키백과, 우리 모두의 백과사전

  ㆍRESTful API : https://restfulapi.net/rest-api-design-tutorial-with-example/

How to design a REST API

  ㆍHTTP Status Codes : https://restfulapi.net/http-status-codes/

HTTP Status Codes