[SpringBoot] RESTful API

Intro. RESTful API

📌 RESTful API : 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스

• 안전하고 신뢰할 수 있음

• 효율적 소프트웨어 통신표준 준수 → 정보교환 지원함

---

1 API

📌 API

• 애플리케이션 프로그래밍 인터페이스
• 다른 소프트웨어 시스템과 통신하기위해 따라야하는 규칙을 정의함
• Client와 Web Resource 사이의 게이트웨이

💡 개발자 : 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있게 API를 생성하고 표시함

🔑 근무기록애플리케이션
	- 직원 전체이름, 날짜범위를 요청하는 API 표시
    - 요청 API → 수신 → 해당 resource 반환
    
	➡️ 요청 API : Client
    ➡️ 웹 resource : 해당 근무기록 데이터

1️⃣ Client

• Web에서 정보(데이터)에 액세스 하려는 사용자

  • ① API를 사용하려는 유저

  • ② 소프트웨어 시스템

2️⃣ Resource

• 다양한 애플리케이션이 클라이언트에게 제공하는 정보

• 데이터의 유형은 다양함

• Client에게 Resource를 제공하는 것 → 서버

• API 사용 → Resource 공유, 보안, 제어, 인증 ➡️ 웹서비스 제공

• API는 특정 내부 Resource에 액세스할 수 있는 Client를 결정하는데 도움이 됨

---

2 REST

📌 Representational State Transfer : API 작동방식에 대해 조건을 부과하는 소프트웨어 아키텍쳐

• 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌음

• REST기반 아키텍쳐 → 대규모 고성능 통신을 안정적으로 지원가능 ✅

• 쉽게 구현 및 수정 가능 → 여러 플랫폼에서 사용 가능

1️⃣ REST API와 RESTful API

용어	의미
REST API	REST 아키텍쳐 스타일을 따르는 API
RESTful API	REST 아키텍쳐를 구현하는 웹서비스

• RESTful API라는 용어는 RESTful 웹 API를 나타냄

• 위의 두 용어는 같은 의미로 사용 가능

2️⃣ REST 아키텍쳐 원칙

💡 균일한 인터페이스

• 모든 RESTful 웹서비스 디자인의 기본

• 서버가 표준형식으로 정보를 전송한다는 의미를 나타냄

• 형식은 서버 애플리케이션에 있는 Resource 내부표현과 다를 수 있음

  • 형식이 지정된 Resource → 표현
  • (서버는 데이터를 text로 저장, HTML 표현 형식으로 전송가능)

💡 무상태

• 서버가 이전의 Request와 독립적으로 Client 요청을 완료하는 통신방법

• Client는 임의의 순서로 Resource를 Request 가능

• Request → 무상태 or 다른 Request와 분리됨

💡 계층화시스템

• Client와 서버 사이, 다른 승인된 중개자 → 연결가능

• 서버 → Request를 다른 서버로 보낼 수 있음

• Client Request → 보안, 애플리케이션, 비즈니스로직 등 여러계층으로 여러서버에서 실행되도록 RESTful 웹서비스 설계가능

• 해당 계층들은 Client에게는 보이지 않음

💡 캐시가능성

• 서버응답시간 개선을 위해 Client 또는 중개자 → 일부 Response를 저장하는 캐싱을 지원함

• Client는 첫번째 Response 이후 캐싱하거나 저장한 다음 캐시에서 데이터를 사용함

💡 온디맨드코드

• 서버 → 소프트웨어 프로그래밍 코드 ➡️ Client에게 전송

• Client 기능을 확장하거나 사용자지정으로 할 수 있음

• 웹사이트에 등록양식 작성 → 브라우저가 잘못된 양식을 즉시 강조표시함

---

3 RESTful API 장점

1️⃣ 확장성

• REST API를 구현하는 시스템 → REST가 Client와 서버 상호작용을 최적화함
  ➡️ 효율적으로 크기조정 가능 ✅

• 성능저하 요인인 통신병목현상을 일으키지 않으면서 확장성을 지원함

  • 무상태 : 서버가 과거 Client Request 정보를 유지할 필요가 없음 → 서버로드 제거함

  • 캐싱 : 일부 Client와 서버 상호작용을 제거함

2️⃣ 유연성

• 완전한 Client와 서버의 분리를 지원함 ⭐️

• 다양한 서버 구성요소 단순화, 분리 각 부분이 독립적으로 발전할 수 있음

• (애플리케이션 로직을 다시 작성하지 않고, 데이터베이스 계층을 변경할 수 있음)

3️⃣ 독립성

• REST API는 사용되는 기술과 독립적임

• API 설계에 영항 ❌ → 다양한 프로그래밍 언어로 Client 및 서버 애플리케이션을 작성할 수 있음

• 통신에 영향 ❌ → 양쪽의 기본기술 변경가능

---

4 RESTful API 작동방식

• RESTful API 기본기능은 인터넷 브라우징과 동일함

• Client는 Resource 필요시 서버에 접속함

📍 REST API 호출 일반단계

	① Client → 서버 ; Request 전송
      (Client는 API 문서 참조하여 서버가 이해하는 방식으로 요청형식지정)
    
    ② 서버 Client 인증 → Request 권한 있는지 확인
    
    ③ 서버 Request 수신하고, 내부적으로 처리
    
    ④ 서버 → Client ; Response 반환
      (Request 성공 여부 포함되어있음)
      (Response에 Request 정보도 포함되어있음)

---

5 API Client Request

1️⃣ 고유 Resource 식별자

• 서버 ; 고유한 Resource 식별자 → 각 Resource를 식별함

• REST 아키텍쳐 기반 웹서비스 서버 → URL로 Resource를 식별함

  • URL : Resource에 대한 경로를 지정함
  • URL : Client Request를 서버에 지정함

2️⃣ 메서드

• HTTP를 이용한 RESTful API 구현 시 사용

• HTTP 메서드 → Resource에 수행해야하는 작업을 서버에 알려줌

💡 GET 메서드

• Client → GET method → 서버의 지정된 URL에 있는 Resource에 액세스함

💡 POST 메서드

• Client → POST method → 서버에 데이터를 전송함

• Request + 데이터표현

• 동일 POST Request 여러 번 전송 시, 동일 Resource 여러 번 생성주의

💡 PUT 메서드

• Client → PUT method → 서버의 기존 Resource Update

• PUT Request는 여러 번 요청해도, 결과는 동일함

💡 DELETE 메서드

• Client → DELETE method → Resource 제거

• 서버 상태를 변경하는 것

• Client의 적절한 인증이 없으면, DELETE Request는 실패함

3️⃣ HTTP Header

• Client와 서버 간에 교환되는 메타데이터

• Request, Response 형식 + Request 상태 등의 정보

💡 데이터

• REST API Request에는 메서드 외, HTTP 메서드가 성공적으로 작동하기 위한 데이터

💡 파라미터

• RESTful API Request에는 수행해야 할 작업에 대한 자세한 정보를 서버에 제공

---

6 RESTful API 인증

📌 RESTful API 인증 : Response를 보내기 전, Request 인증을 함 → 신뢰구축

1️⃣ HTTP 인증

💡 기본인증

• Client → Request Header ➡️ User이름 + 암호

• base64 인코딩 사용

  • 64자의 세트로 변환하는 기술

💡 전달자인증

• 전달자(bearer)인증 : 토큰전달자에 대한 액세스 제어를 제공하는 프로세스

• bearer token : 서버가 로그인 Request에 대한 Response로 생성하는 암호화된 문자열

• Client → Request Header ➡️ bearer token

2️⃣ API 키

• 서버 → 고유생성값 ➡️ 최초 Client에 할당

• Client는 Resource에 액세스 할 때마다 고유 API 키를 사용해 본인을 검증함

• 네트워크 도난에 취약함

3️⃣ OAuth

• 모든 시스템에 대해 매우 안전한 로그인 액세스

• 암호 + token

• 서버는 먼저 암호를 요청한 뒤, 추가 token을 요청함

• 특정 범위 및 수명 → token 재확인 가능

---

7 RESTful API 서버 Response

1️⃣ 상태표시줄

• Request 성공 또는 실패를 알리는 3자리 상태코드

  • 2XX : 성공
  • 4XX, 5XX : 오류
  • 3XX : URL 리디렉션 (다른 URL로 Client를 보내는 것)

📍 200 : 일반 성공 Response

📍 201 : POST 메서드 성공 Response

📍 400 : 서버가 처리할 수 없는 잘못된 Request

📍 404 : Resource 찾을 수 없음

2️⃣ 메시지본문

• Response 본문 → Resource 표현이 포함됨

• Request Header에 포함된 내용을 기반 → 표현형식을 선택함

  • XML : 일반텍스트 (마크업언어)
  • JSON : 일반텍스트 (Key-Value)

{"name" : "mallang", "age" : 22}

3️⃣ Header

• Response에 대한 메타데이터

• 서버, 인코딩, 날짜, 콘텐츠 유형 등