[ Java / 자바 ] API 와 REST API

Interface란?

사물과 인간 사이의 경계에서 상호 간의 소통을 위해 만들어진 물리적 매개체나 프로토콜이다.

 

API란?

애플리케이션(응용프로그램)에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다. 즉, 어떤 프로그램이 제공하는 기능을 애플리케이션에서 사용할 수 있게 만든 매개체다.

 

UI는 컴퓨터와 인간을 연결시키는 사용자 인터페이스이고, API는 컴퓨터나 소프트웨어를 서로 연결하는 인터페이스이다.

 

서버는 프로그램에게 자신이 제공하고자 하는 데이터나 기능을 제어할 수 있는 API로 만들면, 접근 권한이 있는 프로그래머나 프로그램이 API를 통해 데이터를 요청해 사용할 수 있게 된다.

 

즉 API를 식당으로 예를 들자면 메뉴판에 적혀 있는 메뉴라 말할 수 있다. 

사장(서버)님은 자신이 팔고자 하는 메뉴를 메뉴판에 적는다 -> 이때 메뉴는 API 메뉴판은 API List이다.

손님(애플리케이션)은 메뉴판(API List)을 보고 구매하고자 하는 메뉴(API)를 사장님(서버)에게 주문(요청)한다.

---

 

Rest API는 대중적으로 가장 많이 사용되는 애플리케이션 인터페이스이다. 이 인터페이스를 통해 클라이언트는 서버에 접근하고 자원을 조작할 수 있다.

Rest란?

Rest란Representational State Transfer 의 약자로, 월드 와이드 웹(WWW)와 같은 분산 하이퍼미디어 시스템 아키텍처의 한 형식이다. 주고받는 자원(Resource)에 이름을 규정하고 URL에 명시해 HTTP Method(GET, POST, PUT, DELETE)를 통해 자원의 상태를 주고받는 것을 의미한다.

---

 

Rest API란?

API는 Application Programming Interface의 약자로, 애플리케이션에서 제공하는 인터페이스이다. API를 통해 서버 또는 프로그램 사이를 연결할 수 있다. 즉 REST API는 REST 아키텍처를 따르는 시스템/애플리케이션 인터페이스라고 볼 수 있다. 또한 REST 아키텍처를 구현하는 웹 서비스를 RESTful하다 라 표현한다.

---

특징

유니폼 인터페이스

유니폼 인터페이스란 '일관된 인터페이스'를 의미한다. 즉, REST 서버는 HTTP 표준 전공 규약을 따르기 때문에 어느 언어로 만들어졌느냐와 상관없이 플랫폼과 기술에 종속되지 않고 타 언어, 플랫폼, 기술 등과 호환해 사용할 수 있다.

---

무상태성

REST는 무상태성(stateless)이란 특성을 갖는다. 이는 서버에 상태 정보를 따로 보관하거나 관리하지 않는다는 의미이다.

서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키 정보를 별도 보관하지 않는다.

한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리해 비지니스 로직의 자유도가 높고 설계가 단순하다. -> 불필요한 정보를 관리하지 않는다.

---

캐시 가능성

REST는 HTTP 표준을 그대로 사용해 HTTP 캐싱 기능을 적용할 수 있다. 이를 위해 응답과 요청이 모두 캐싱 가능한지(Cacheable) 명시가 필요하며, 캐싱이 가능한 경우 클라이언트의 캐시에 저장하고 해당 데이터를 가져다 사용한다.

이는 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선된다.

---

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

REST 서버는 API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계한다. 이 구성은 서로에 대한 의존성을 낮추는 기능을 한다.

---

REST의 URL 설계 규칙

url 규칙

• url의 마지막에는 '/'를 포함하지 않는다.
  • 옳은 예) http://localhost.com/product
  • 잘못된 예) http://localhost.com/product/
• 언더바(_)는 사용하지 않는다. 대신 하이픈(-)을 이용한다.
  • 하이픈은 리소스의 이름이 길어지면 사용함
  • 옳은 예) http://localhost.com/provider-company-name
  • 잘못된 예) http://localhost.com/provider_company_name
• URL에는 행위(동사)가 아닌 결과(명사)를 포함한다.
  • 옳은 예) http://localhost.com/product/123
  • 잘못된 예) http:/localhost.com/delete-product/123
  • 행위는 HTTP 메서드로 표현할 수 있어야 합니다.
• URI는 소문자로 작성해야 합니다. 
  
  • URI 리소스 경로에는 대문자 사용을 피하는 것이 좋다.
  • 일부 웹 서버의 운영체제는 리소스 경로 부분의 대소문자를 다른 문자로 인식하기 때문이다. 이로 인해 오류가 발생할 수 있다.
• 파일의 확장자는 URI에 포함하지 않는다.
  • HTTP에서 제공하는 Accept 헤더를 사용하는 것이 좋다.

---

질문 1.

URL에 행위(동사)를 표현하지 말라 하는데 그럼 product에 대한 추가와 삭제 모두

http://localhost.com/product/123 이렇게 작성하고 밑에 코드와 같이 작성하는 것인가?

 

js로 예를 들면

axios.post(https://localhost.com/product/123)
axios.delete(https://localhost.com/product/123)

 

개발자 커뮤니티 디코에 무러봄!!

 

맞다고 한다.

그리고 상황은 유동적으로 변하니까 "참고" 만 하라고 하셨다.

 

참고

스프링부트 핵심가이드 - 장정우 지음