API / HTTP Packet / HTTP Method

[ 211030 5주차 강의 정리 ] + 워크북 & 스터디 내용 추가 (211106)

 

❖  API

1. 정의

    : Application Programming Interface

      응용 프로그램(Application)에서 사용할 수 있도록

      운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든(Programming)

      인터페이스(Interface)

 

---

* Interface

1주차 워크북 중..

1. 인터페이스

     : 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면

       사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템

       5주차 강의 - 서로 다른 개체 끼리의 상호작용을 돕는 시스템

 

2. GUI (Graphical User Interface)

     : 사용자가 편리하게 사용할 수 있도록 입출력 등의 기능을 그래픽으로 나타낸 것

 

3. CLI (Command-line Interface)

     : 가상 터미널 / 터미널을 통해 사용자와 컴퓨터가 상호 작용하는 방식

 

---

2. 예시 - 당근마켓 전화번호 인증

❏  클라이언트의 입장

      1. 인증 번호 요청 클릭 (API 요청)

      2. 인증 번호 받기

      → 클라이언트는 어떻게?에 대해서는 관심이 없음

 

❏  서버 개발자의 입장

      : 전화번호 인증 기능과 클라이언트가 상호 작용을 할 수 있도록 API를 만들어주어야 함

---

3. API = HTTP Method + URI

---

* URI? URL?

❏  URI

Uniform Resource Identifier (통합 자원 식별자)

URI를 통해서 정보 리소스를 고유하게 식별, 위치 지정 가능

URI의 두가지 형태 - URL, URN

 

❏  URL

Uniform Resource Locator (통합 자원 지시자)

특정 서버의 한 리소스에 대한 구체적인 위치를 서술

(리소스가 정확히 어디에 있고 어떻게 접근할 수 있는가?)

 

URL의 한계

URL은 주소일 뿐 실제 이름이 아니다! (특정 시점에 어떤 것에 위치한 곳인지 알려주는 것)

→ 리소스가 옮겨지면 해당 URL을 더는 사용할 수 없다

 

∴ URI ⊃ URL

모든 URL은 URI지만

모든 URI는 URL라고 말할 수 없음

 

---

4. API Sheet

API 명세서

어떤 API인지 클라이언트가 알 수 있도록 문서화한 것

(API : API Sheet = 요리 : 메뉴판)

 

클라이언트와 서버가 소통하는 통로이기 때문에, 가능한 모든 정보를 상세히 기재하는 것이 좋음

 

https://velog.io/@banjjoknim/API-명세서-작성하기

 

---

❖ HTTP Packet

---

 

* HTTP (복습!)

인터넷에서 웹 브라우저로 문서나 파일을 표시하기 위한 공통 규약

메세지의 구조 및 클라이언트와 서버가 메세지를 어떻게 교환하는지에 대한 정의

 

---

2주차 강의 중.. 2021.10.03 - [Computer Science/Server] - 클라이언트 - 서버 관계론

 

---

ex. 박스 소포

      Header : 운송장 label (클라이언트의 정보)

      Body : 내용물을 담는 전체 공간 (특정 데이터를 담아 서버에게 요청을 보낼 수 있음)

      Data : 내용물

 

---

* 상태 코드와 메세지

200 OK : 요청 성공

301 Moved Parmanently : 요청 객체가 영원히 이동됨

400 Bad Request : 서버가 요청을 이해할 수 없다는 일반 오류 코드

404 Not Found : 요청 문서가 서버에 존재하지 않는다

500 Internal Server Error : 내부 서버가 오류가 있어 요청을 수행하지 못함

 

---

❖ HTTP Method

1. 정의

     : 서버에 요청을 보내는 방법

       HTTP 메소드를 사용할 때는 의미 단위로 생각

       (DB에서는 PUT 작업을 수행하더라도, 클라이언트 입장에서 삭제하는 행위면 DELETE로 명명해야 함)

       → 7주차 강의 : 실제 DB operation 기준으로 명명

---

2. 종류

CRUD : Create, Read, Update, Delete

각각에 해당하는 HTTP 메소드 존재

 

[ Create ]

❏  POST

서버가 처리할 수 있는 자료를 보냄 (생성)

서버가 클라이언트의 폼 입력 데이터의 수락을 요청

→ 클라이언트는 서버로 HTTP Body에 data를 전송

---

data 전송 시 어떻게 담을까?

* Data Format

   : 데이터의 표현 형식 (일종의 약속)

 

❏  일반 Text 데이터

     : 비정형 데이터

 

❏  CSV (comma separated value)

     : 별도의 구분 기호로 데이터를 구분하여 표시

       다른 사람이 데이터를 구분하기 어려움

 

❏  XML (extensive markup language)

     : HTML을 개선하여 만듦

       서로 다른 기종 간의 데이터 교환을 위해 등장

       인코딩 방식 : utf-8

 

❏  JSON (JavaScript object notation)

     : (속성 : 값)으로 데이터 표현

       → 많은 양의 데이터 표현에 유리

---

* XML vs. JSON

위 XML, 아래 JSON

JSON을 더 많이 쓴다! 왜?

1. 종료 태그 없음

2. 더 짧음 → 더 빨리 읽고 씀

3. XML : 배열 사용 불가 / JSON : 가능

4. 더 직관적으로 보이는 듯!

 

---

[ Read ]

❏  GET

URI에 해당하는 정보의 전송 요청을 보냄 (조회)

지정된 리소스(URI)를 요청

주소에 Path Variable / Query Parameter를 통해서 요청하는 데이터를 전송!

---

* Path Variable & Query Parameter

   : 데이터를 전송하는 방법들

 

❏  Path Variable

/users/123 # 아이디가 123인 사용자 가져오기

경로를 변수로서 사용

 

❏  Query Parameter

/users?id=123 # 아이디가 123인 사용자 가져오기

 

각각 언제 사용?

1. Resource 식별 시 → Path Variable

2. 정렬 또는 필터링 시 → Query Parameter

 

---

[ Update ]

❏  PUT

자료를 전송하여 해당 URI에 자료를 저장 (수정)

클라이언트가 전송한 데이터를 지정한 URI로 대체

→ 클라이언트는 서버로 HTTP 바디에 데이터를 전송

 

❏  PATCH

자원의 부분 교체 (일부 수정)

 

[ Delete ]

❏  DELETE

해당 URI의 자원/정보를 삭제