• API: 메뉴판 → 메뉴판을 보고 어떤 음식이 있는지 확인할 수 있어 일종의 **‘사전에 약속된 규칙’**이라고 할 수 있음

  • 메뉴판은 단지 문서에 불과

    ⇒ API도 권장하는 어떤 규칙으로 결과나 return 값을 받아야 실체가 있다고 할 수 있음

• API Server: 웨이터 → 손님이 요청을 할 수 있게 중간다리 역할을 함 + 요청을 처리하고 response나 return 값을 손님에게 전달

  • 웨이터=API Server가 없어도 client가 service server와 소통할 수 있으나, 이 경우에는 service server의 역할과 부담이 커짐

• Service server: 쉐프 → 손님의 요청을 실질적으로 처리하는 일을 함

• API 응답: 보통 전달받는 응답은 json 형태

  • JSON: 말 그대로 자바스크립트 (Javascript) 에서 'Object' 를 표기하는 방식

HTTP API

• HTTP: 컴퓨터 통신 규약 중 하나
  • 하나의 컴퓨터가 다른 컴퓨터와 소통을 하고 싶을 때에 (파일을 받거나 전달하거나 등) 정해진 규칙과 틀을 준수해야 원활한 소통이 가능한데, 이렇게 정해진 규칙들을 하나의 규약(protocol)이라 함
  • 크게 HTTP request, HTTP response로 나뉨

• HTTP request: 한 컴퓨터가 다른 컴퓨터에 리소스 요청을 보냄

  • 요청을 하는 컴퓨터: client, 요청을 받는 컴퓨터: server
  • 은행에 계좌 이체 할 때: 고객=client, 은행원=server

• CRUD에 사용되는 HTTP 메소드: GET, POST, PUT/PATCH, DELETE

  ** CRUD : 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말

  • GET: 특정 리소스를 달라고 할 때 사용
    • 예) 페이지를 로딩할 때
  • POST: 서버 측의 특정 리소스를 저장할 때 사용
    • 예) 회원가입할 때 특정 유저의 정보를 서버에 저장
  • PUT/PATCH: 서버 측의 특정 리소스를 업데이트할 때 사용
    • PUT: 데이터를 전부 바꿀 때
    • PATCH: 부분적으로 변경
    • 예) 사용자 닉네임 변경
  • DELETE: 서버 측의 특정 리소스를 삭제할 때 사용
    • 예) 유저 탈퇴
  • 꼭 DELETE으로 삭제를 해야 하고 PUT으로 데이터 변경해야 하는 건 아님
  • client와 server 사전에 약속했으면 작동에 문제 x

• HTTP response: HTTP 규약에 따른 응답

  • 응답을 보낼 때에는 상태 코드도 있지만, 때에 따라 문자열이나 JSON 등을 이용해서 데이터를 함께 실어서 보내기도 함
  • 100번대에서 500번대까지 HTTP 상태 코드들
    • 100 번대 : 정보 응답
    • 200 번대 : 성공 응답
    • 300 번대 : 리다이렉션 메시지
    • 400 번대 : 클라이언트 에러 응답
    • 500 번대 : 서버 에러 응답

• 예시

  

  • 'Request Method': 이전에 봤던 HTTP 요청 메소드 중 GET, 리소스를 가져온다는 뜻인 메소드를 사용함
  • 'Status Code' : 200 은 'OK', 성공했다는 뜻 ⇒ 여기에서는 GET 요청이 성공적이었다는 뜻
  • 'Request URL' : 누가 요청을 하고 있는지를 담고 있음
  • 'Remote Address' : 어느 리모트 서버에 요청을 하고 있는지 알려줌 → 157.245.183.96 의 443 포트에 요청을 보내고 있음
  • 'Referrer Policy' : 요청을 보내는 곳이 당사자인지, 타 웹사이트에서 연결된 건지 등 알려줌 → 현재는 'no-referrer' 로 현 웹사이트에서 보내고 있음

REST API

REpresentational State of Transfer

• 웹에서 활용하게 되는 API가 REST의 가이드라인들은 다 따르면 해당 API를 RESTful API라고 칭함

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

• REST API에서 GET 활용 예시 : GET 요청은 REST 에서 정보나 리소스를 가지고 올 때만 사용하라고 제시됨 = 즉 서버에 기록된 데이터나 리소스를 변경할 때 사용해서는 안된다는 뜻

  • 기존 리소스에 대한 변경을 하지 않고 그저 가져오는 역할을 하기 때문에 '안전한' 메소드
  • 따라서 하나의 GET 요청은 매번 동일한 결과를 보여주어야 함(서버의 리소스가 변경되지 않았다는 가정하에)

  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 정보만 가지고 올 거라는 예상 가능

• REST 에서 주로 사용되는 HTTP 상태 코드

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