API

API(Application Programming Interface)

앱 사이의 소통하기 위한 일종의 약속의 집합

프로그램마다 API가 다르기도 하고, 없어서 새로 만들기도 함

 

Web API

네트워크를 매개로 HTTP 프로토콜을 사용해 요청과 응답을 주고받는 API

 

즉, 클라이언트(요청자)와 서버(응답자)가 소통하기 위해 정해둔 방식임.

---

@ResponseBody

이번 강의의 핵심인 @ResponseBody 어노테이션

return 객체를 그대로 web에 보여줌.

java/hello/hello_spring/controller/helloController.java

이번엔 처음으로 문자열이 아닌 객체를 return 함.

그랬더니 json 형태로 나타남.

(key : value 형태)

 

* 예전에는 json과 xml이 격돌을 했던 시기도 있었지만, 현재는 대부분이 json 파일로 주고 받는다고 함.

---

HTTP 요청·응답 구조

json은 데이터 포맷일 뿐 HTTP 프로토콜을 사용하여 요청과 응답을 주고받는 구조와는 다르다는 것을 알아야 함.

 

1. URL

2. HTTP 메서드

• GET
• POST
• PUT / PATCH
• DELETE

3. 헤더

• 요청·응답에 붙는 메타정보(인증, 콘텐츠 타입 등)

4. 바디

• 요청 시 전송 데이터, 또는 응답으로 돌아오는 실제 내용(JSON, XML 등)

5. 상태 코드

• 200 OK
• 201 Created
• 400 Bad Request
• 401 Unauthorized
• 404 Not Found
• 500 Internal Server Error 
• 등등 커스트마이징도 가능

---

RESTful API 원칙

REST(Representational State Transfer)는 웹의 아키텍처 스타일로, 이를 잘 따르는 API를 “RESTful”하다고 부른다.

 

1. 리소스 중심
   URL는 데이터(리소스)를 가리키고, HTTP 메서드로 행위를 표현함
   URL만 보고 어떤 데이터를 다루는지 바로 알 수 있어야, 클라이언트와 서버 간 의사소통이 명확해짐
2. 무상태
   각 요청이 독립적이어야 하며, 서버는 이전 요청의 상태(세션)를 저장하지 않음.
   서버 간 로드 밸런싱(확장성), 특정 서버에 종속되지 않아 장애 복구가 간단(신뢰)
3. 표현
   JSON ·XML 등의 포맷으로 리소스 상태를 표현
4. 자체 서술성
   헤더 ·상태 코드만으로 요청 ·응답 의미를 파악 가능
   명시적인 표준(HTTP 상태 코드·헤더)만으로도 클라이언트가 어떻게 처리할 지 판단할 수 있어야, 문서/버전 의존성을 최소화 할 수 있음.
5. HATEOAS (선택)
   응답에 다음 행동을 안내하는 링크를 담음
   클라이언트가 URI를 하드코딩하지 않아도, API가 안내해 주는 링크만 따라가면 애플리케이션 흐름을 구현할 수 있음.

로드 밸런싱 : 여러 대의 서버에 네트워크 트래픽을 분산하여 특정 서버에 부하가 집중되는 것을 방지하고, 시스템의 안정성과 성능을 향상시키는 기술