REST API

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

 

* 복습

API = HTTP Method + URI

5주차 강의 중.. 2021.11.07 - [Computer Science/Server] - API / HTTP Packet / HTTP Method

 

리소스 식별 시

URN (Uniform Resource Name) - 이름 / URL -  위치

URN은 거의 사용하지 않기 때문에 URI ≒ URL라고 해도 무방

 

---

❖ REST API

1. REST

Representation State Transfer

강의 - HTTP로 정보를 보낼 때, URI를 어떻게 설계하고 어떤 메소드를 사용할 것인지 표준으로 정해놓은 약속

웹 애플리케이션 간 데이터 통신을 허용하는 API를 구축하는 방법을 정의

(웹 서비스와 모바일 애플리케이션 경량화의 필요에 맞춘 아키텍처 원칙 세트)

---

* API? (복습)

   : 애플리케이션 소프트웨어를 구축하고 통합하는 정의 및 프로토콜 세트

 

즉, 컴퓨터나 시스템과 상호 작용하여 정보를 검색하거나 기능을 수행하고자 할 때

API는 사용자가 원하는 것을 시스템에 전달할 수 있게 지원하여 시스템이 이 요청을 이해하고 이행하도록 할 수 있음

 

→ 사용자 또는 클라이언트, 그리고 사용자와 클라이언트가 얻으려 하는 리소스 사이의 조정자

 

API(애플리케이션 프로그래밍 인터페이스)란 - 개념, 기능, 장점

 

---

2. RESTful API

강의 - 리소스 & 행위 분리

           • URI : Resource(행위의 목적, 대상) 식별

           • Method : 해당 Resource에 대한 행위(CRUD)

→ HTTP URI를 통해 자원(Resource)을 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용
(자세한 설명)

 

ex. /members

회원 목록 조회 API	GET /members
회원 가입 API	POST /members
회원 정보 수정 API	PATCH /members
회원 탈퇴 API	DELETE /members

 

---

[ RESTful 애플리케이션이 갖춰야 할 6가지 아키텍처 가이드라인 ]

약간의 tmi....

 

* Architecture

비지니스 요구 사항을 만족하는 시스템을 구축하기 위해서 전체 시스템에 대한 구조를 정의한 문서

(시스템을 구성하는 컴포넌트와, 그 컴포넌트 간의 관계, 그리고 컴포넌트가 다루는 정보를 정의)

(자세한 설명)

 

1. 클라이언트-서버 아키텍처 

    : 클라이언트, 서버 및 리소스로 구성되었으며, 요청이 HTTP를 통해 관리됨

      이러한 요청을 수신하면 RESTful API가 HTML, XML, 일반 텍스트, JSON 등의 형식으로 메시지를 반환할 수 있음

 

2. 스테이트리스 클라이언트-서버 커뮤니케이션

* Stateless

과거 트랜잭션에 대한 정보 또는 참조가 저장되지 않음 → 각 트랜잭션은 모두 처음부터 시작됨

        * Transaction

           - 직역 : 거래

           - 데이터베이스 트랜잭션 : 데이터베이스 관리 시스템에서 상호작용의 단위

단일 요청에 대한 하나의 응답

ex. 온라인 검색창 (질문을 입력 후 엔터키를 눌렀을 때)

 

→ 스테이트리스 클라이언트-서버 커뮤니케이션 ?

     : 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음

       (대신 세션의 상태에 대한 정보는 클라이언트에 저장됨)

 

3. 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터

* Cache

   : 빠른 데이터 처리를 위한 임시공간

     (요청 결과를 미리 저장해서 빠르게 서비스를 제공)

 

4. 표준화된 형식으로 정보를 전송할 수 있도록 구성 요소 간 통합된 인터페이스

     (1) 요청된 리소스가 식별 가능하며 / 클라이언트에 전송된 표현과 분리되어야 한다.

     (2) 수신한 표현을 통해 / 클라이언트가 리소스를 조작할 수 있어야 한다.

           (이렇게 할 수 있는 충분한 정보가 표현에 포함되어 있기 때문)

     (3) 클라이언트에 반환되는 자기 기술적(self-descriptive) 메시지에

           클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 한다.

     (4) 하이퍼 미디어

           : 클라이언트가 리소스에 액세스 한 후 / 하이퍼링크를 사용해 / 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 한다.

 

5. 클라이언트-서버 간의 상호 작용을 계층적으로 조정할 수 있도록 계층화된 시스템 제약

     : 요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을

       클라이언트가 볼 수 없는 계층 구조로 체계화

 

6. 코드 온디맨드 (선택 사항)

     : 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 기능

       (가시성이 감소할 수 있으므로(???) 선택적 가이드라인임)

 

https://www.redhat.com/ko/topics/api/what-is-a-rest-api

---

3. RESTful API 설계 방법

❏  URI에는 되도록 명사를 사용한다

❏  언더바('_'), 대문자는 사용하지 않는다

❏  계층 관계를 나타낼 때는 '/' 사용

❏  메소드는 실제 DB operation 기준으로 정한다!

 

ex. 회원 탈퇴 API

      DELETE /members 이렇게 아예 데이터를 삭제하는 경우는 드묾

      탈퇴 여부 column의 값을 변경 (isDeleted N→Y / status A(active)→D(deleted))

      → PATCH /members

---

* API 호출 시 정보를 담는 방법?

1. Path Variable & Query Parameter

    5주차 강의 중 .. 2021.11.07 - [Computer Science/Server] - API / HTTP Packet / HTTP Method

ex.

 

2. Body

ex.

 

❏  PUT / POST / PATCH : HTTP Packet Body 또는 Path Variable & Query Parameter에 data를 담아서 전송

❏  GET / DELETE : Path Variable & Query Parameter만을 사용