[Spring] RESTful API란?

yunSeok·2023년 10월 19일

API REST API Spring restful api

Spring

목록 보기

2/4

프로젝트를 진행하다보면 API를 사용했다, REST를 사용했다, REST API... 를 많이 접하게 된다. 그래서 REST는 뭐고 API는 정확이 뭔데!? 라는 의문에서 시작해보겠습니다...

API란?

(Application Programming Interface)

응용 프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스입니다.

특정 데이터를 공유할 경우 어떠한 방식으로 정보를 요청할건지, 어떠한 데이터를 제공받을 건지에 대한 규격을 정해놓은 인터페이스라고 할 수 있습니다.

서버와 데이터베이스에 대한 출입구 역할을 합니다.

소프트웨어가 다른 소프트웨어로 부터 지정된 형식으로 요청을 받을 수 있는 수단입니다.

✔️ HTTP API 라고도 할 수 있습니다. HTTP(네트워크 상의 통신 방법)를 사용하여 프로그램끼리 또는 클라이언트와 서버끼리 소통하는 API를 말합니다. OPEN API(= Public API), facebook API, kakao API, naver API, google API, youtube API 등의 대부분 API는 HTTP라는 통신 규칙으로 소통하는 API입니다.

◼ OPEN API(= Public API) : 회사 내부에서 사용하는 API를 외부의 다른 개발자가 사용할 수 있도록 공개적으로 오픈한 것을 말합니다.

📌 정리하자면 애플리케이션에서 데이터를 읽거나 쓰기 위해 사용하는 인터페이스입니다.

❗❓❗❓❗❓....
라고는 하지만 이해가 조금 어려운데요..!

💨 예시를 한번 들어보겠습니다.
유튜브에서 구독한 채널의 영상만 나오는 웹 사이트를 만든다면,
웹 페이지에서 정보를 요청했을 때 유튜브가 갖고 있는 데이터베이스에서 해당 구글계정의 구독목록을 응답해서 반환해주는 일종의 소통을 하겠죠?
이러한 Request(요청) Response(응답)의 상호작용을 "API"라고합니다

🔹 [참고] Endpoint란?

API는 두 시스템(어플리케이션)이 상호작용 할 수 있게 하는 프로토콜의 집합이라면, Endpoint란 API가 서버에서 리소스에 접근할 수 있도록 가능하게 하는 URL이라 할 수 있습니다.

엔드포인트는 API 통신 시스템의 최종 접점입니다. 여기에는 서버 URL, 서비스 및 시스템 간에 정보가 송수신되는 기타 특정 디지털 위치가 포함됩니다. 엔드포인트는 두 가지 중요 사항이 있습니다

1. 보안
API 엔드포인트는 시스템을 공격에 취약하게 만듭니다. API 모니터링은 오용을 방지하는 데 중요합니다.

2. 성능
API 엔드포인트, 특히 트래픽이 많은 엔드포인트는 병목 현상을 일으키고 시스템 성능에 영향을 줄 수 있습니다.

✅ API의 작동

아래 사진은 위에서 설명한 API 구조입니다.

이러한 API를 어떻게 사용할 것인지, 어떻게 디자인해서 만들것인지 정의한 것이 있습니다.

SOAP API
단순 객체 접근 프로토콜을 사용합니다. 클라이언트와 서버는 XML이라는 데이터 포멧을 사용하여 메시지를 교환합니다. 과거에 더 많이 사용되었으며 유연성이 떨어지는 API입니다.

✔️ REST API
요즘 웹에서 볼 수 있는 가장 많이 사용되고 유연한 API입니다. 클라이언트가 서버에 요청을 데이터로 전송합니다. 서버가 이 클라이언트 입력을 사용하여 내부 함수를 시작하고 출력 데이터를 다시 클라이언트에 반환합니다.

RPC API
원격 프로시저 호출이라고 합니다. 클라이언트가 서버에서 함수나 프로시저를 완료하면 서버가 출력을 클라이언트로 다시 전송합니다.

Websocket API
Websocket API는 JSON 객체를 사용하여 데이터를 전달하는 또 다른 최신 웹 API 개발입니다. WebSocket API는 클라이언트 앱과 서버 간의 양방향 통신을 지원합니다. 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적입니다.

✅ SOAP REST 차이 (작성예정)

SOAP REST
복잡하다 단순하다.
규칙이 많다 규칙적음
어렵다 쉽다

REST란?

(Representational State Transfer)

하나의 URI는 하나의 고유한 리소스를 대표하도록 설계된다는 개념에 전송방식을 결합해서 원하는 작업을 지정하는 것입니다.
HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

GET : Read 조회시 사용
POST : Create 추가할때 사용
PUT : 정보를 통째로 변경할때
PATCH : 정보의 일부만을 변경할때
DELETE : 정보를 삭제할 때

Resource(자원) URI, Method(처리), Message의 3가지 요소로 구성된다.

REST 4가지 구성요소

1. Resource(자원의 식별)

요청 내에 기술된 개별 자원을 식별할 수 있어야 합니다. 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터베이스 레코드를 HTML, XML이나 JSON 등의 형식으로 전송합니다.

➜ 위에서 예를 든 URI의 개념 같은 건데요, 자원(리소스)이 서버가 받게 되는 데이터를 분리해야 한다는 것입니다. 이를 JSON 같은 행태로 전송하여 서버가 자원과 데이터를 각기 다르게 인식할 수 있어야 한다는 것입니다.

2. Verb(메시지를 통한 리소스의 조작) 행위

클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보가 됩니다.

➜ HTTP 메시지를 통한 리소스의 조작인데, 이것은 간단하게 말하면 HTTP의 메서드로 (POST는 등록 / GET은 조회 등) 리소스를 변경, 삭제 그리고 조회할 수 있게 해야한다.

3. Representations(자기 서술적 메시지) 표현

각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 합니다.
미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 합니다.

➜ HTTP에는 다양한 문서 양식(인코딩)이 있다, 예를 들어 단순한 text라면 text/plain, JSON이라면 application/json 이렇게 다양한 양식들을 구분하여 서버에게 정확히 알려주어야 한다는 것입니다.

4. HATEOAS(애플리케이션의 상태에 대한 하이퍼 미디어)

리소스에 접근할 때, URI를 제공해주어야 합니다.

➜ 애플리케이션의 상태가 하이퍼미디어에 의해 변경되는 것, 링크를 통해서 클라이언트는 서버에게 애플리케이션의 상태를 변경할 수 있게끔 요청할 수가 있어야 합니다.

REST의 6가지 제약조건/아키텍쳐 스타일

1. Client-ServerI(서버-클라이언트 구조)

클라이언트와 서버의 역할을 구분하는 것입니다. 이를 구분하는 것은 리소스의 유무인데, 리소스를 요청하는 쪽이 Client, 리소스를 가지고 있는 쪽이 Server가 됩니다.
Client 는 사용자 인증이나 세션 같은 정보들을 직접 관리하고 책임지게 되고, Server는 비즈니스 로직에 의한 처리와 저장을 책임집니다.

이로써 서로 간의 의존성이 줄어들게 됩니다.

2. Stateless(무상태)

HTTP 프로토콜은 기본적으로 Stateless 즉 무 상태이기 때문에 REST 역시 무상태성을 갖는다.
서버가 요청 간에 클라이언트 데이터를 저장하지 않음을 의미합니다.
유, 무의 의미인데, 클라이언트가 가지고 있는 세션과 같은 정보는 서버 쪽에서 관리하는게 아니기 때문에 요청하는 비즈니스 로직만 신경 쓰면 됩니다.
서버에 대한 클라이언트 요청은 웹 사이트를 방문하기 위해 브라우저에 입력하는 URL과 유사합니다.

서버에게 일관적인 처리 방식을 처리하게 해 주기 때문에 서버 쪽의 부담이 줄어들고 클라이언트가 누리는 서비스의 자유도도 높아진다

3.Cacheable(캐시 처리 가능)

자기 서술적 메시지로 인해 독립적인 처리가 가능하게 되어 Caching이 가능해집니다. HTTP의 캐시 기능을 사용할 수 있다는 의미입니다.
Last-Modified 태그나 E-Tag를 통한 캐싱도 가능해집니다.

대부분 서비스 시스템의 조회성 트랜잭션이 유발하는 비효율적인 구조를 캐시를 사용함으로써 대량의 요청도 효율적으로 처리할 수 있는 것이다.

4.Layered System(계층화)

계층 사이 사이 필요 기능을 추가할 수 있어 비즈니스 로직은 구조상 유연해질 수 있습니다.

REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.

5.Uniform Interface(인터페이스 일관성)

HTTP의 표준만 따른다면 모든 플랫폼에서 사용이 가능합니다. 즉 특정 언어나 기술에 종속되지 않는 것입니다.
서버와 클라이언트가 각각 독립적으로 진화한다.
서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.

✅ Uniform Interface의 4가지 제약조건

1. identification of resource

리소스가 식별되어야 한다. => URI로 리소스를 표현해야 한다. test.com/members

회원에 대한 CRUD를 구현한다면 members라는 리소스를 꼭 표현해야 한다는 것이다

2. resource manipulation through representations

표현을 통해 리소스를 조작해야 한다 => HTTP method로 리소스를 조작해야 한다.
리소스에 대한 행위를 표현해야 한다. 행위를 표현해야 하나 이를 URI에 담아서는 안된다

POST / GET / PUT / DELETE와 같은 HTTP 메서드로 구분하여 표현해야 한다
회원정보를 가져올 때는 GET, 회원 추가 시의 행위를 표현하고자 할 때는 POST METHOD를 사용하여 표현합니다.

📌 URI 설계 규칙

슬래시(/) 는 계층을 나타낼때 사용한다.

   http://localhost:8080/notice/list (o)
   http://localhost:8080/review/list (o)

URI의 마지막에는 / 를 사용하지 않는다.

   http://localhost:8080/notice/list/ (x)
   http://localhost:8080/notice/list (o)

URI의 언더바(_) 는 사용하지 않는다.

   http://localhost:8080/notice/notice_list (x)
   http://localhost:8080/notice/list (o)

URI 경로는 소문자로 작성한다.

   http://localhost:8080/NOTICE/LIST (x)
   http://localhost:8080/notice/list (o)

파일의 확장자는 포함하지 않는다.

   http://localhost:8080/notice/123.jpg (x)
   http://localhost:8080/notice/list (o)

하이픈(-)은 URI의 가독성을 높이는데 사용할 수 있다.

  http://localhost:8080/notice/list-njasd-asd-qwe (o)

3. self-descriptive messages: 메세지가 스스로를 설명할 수 있어야 한다. (메세지만 보고서 그 의미를 이해를 할 수 있어야한다.)

media-type을 정의
Link header에 명세를 추가
self-descriptive하게 메세지를 제공함으로서, 서버가 제공하는 내용을 클라이언트가 명확히 이해할 수 있게 됩니다.

중요한 내용이라 따로 작성하였습니다❗️
다음글 : self-descriptive messages

4. Hypermedia As The Engine Of Application State (HATEOAS): 어플리케이션의 상태를 Hypermedia를 통해 전이 해야한다.

클라이언트를 개발하는 사람들이 특정 메소드로부터 올 수 있는 결과 동작에 대해 예측하는 것이 가능해지고, API가 변경되더라도 키가 바뀌지 않는 한 URI로 주어진 링크(link)만 유지하면 되므로 별도의 대응이 요구되지 않게 된다는 것, 즉 클라이언트가 제공되는 API의 변화에 일일이 대응하지 않아도 되는 편리함을 제공합니다.

중요한 내용이라 따로 작성하였습니다❗️
다음글 : HATEOAS

6. Code-On-Demand (optional)

server에서 코드를 client로 보내서 실행할 수 있어야 합니다. ( ex. HTML의 javascript )
보안상 추천하지 않는다고 합니다.

REST 장단점

👍🏻 장점

HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없습니다.

HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능합니다.

REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있습니다.

서버와 클라이언트의 역할을 명확하게 분리합니다.

👎🏻 단점

표준 자체가 존재하지 않아 정의가 필요하며 작성자 마다 다를 수 있습니다.
HTTP Method 형태가 제한적입니다.

Header 정보의 값을 처리해야 하므로 전문성이 요구됩니다.

REST API란?

사실 말 그대로 "API" 를 "REST" 하게 만드는 것이 REST API이다.

REST API는 HTTP 프로토콜을 따르면서 아래의 4가지 가이드 원칙을 지켜야 한다.
이러한 제약 조건들을 완벽하게 지키면서 개발하는 것을 RESTful API라고한다.

RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 API의 이해도 및 호환성을 높이는 것이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.

REST API 의 4가지 장점

통합
API는 새로운 애플리케이션을 기존 소프트웨어 시스템과 통합하는 데 사용됩니다. 각 기능을 처음부터 작성할 필요가 없기 때문에 개발 속도가 빨라집니다. API를 사용하여 기존 코드를 활용할 수 있습니다.
혁신
새로운 툴에 유연하게 대처가 가능하며, 전체 코드를 다시 작성할 필요 없이 API 수준에서 변경하여 이를 수행할 수 있습니다.
확장
API는 다양한 플랫폼에서 지원합니다. 웹 사이트, Android, iOS 등을 모두 지원하기 때문에 API를 사용하여 내부 데이터베이스에 유사한 액세스 권한을 부여할 수 있습니다.
유지 관리의 용이성
API는 두 시스템 간의 게이트웨이 역할을 합니다. API가 영향을 받지 않도록 각 시스템을 변경 한다면, 한 시스템의 향후 코드 변경이 다른 시스템에 영향을 미치지 않습니다.

📌 정리

REST의 제약 조건 중에서 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못한다

REST를 따를 것인지는 API를 설계하는 사람이 스스로 판단하여 결정해야 한다

REST를 따르겠다면 Self-descriptive와 HATEOAS를 만족해야한다

Self-descriptive는 custom media type이나 profile link relation 등으로 만족 시킬 수 있다

HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족 시킬 수 있다

REST를 따르지 않겠다면 HTTP API라고 부를 수 있다.

✅ REST 기반으로 API를 만듦으로써 확장성과 재사용성을 효율적으로 높이고 유지보수와 운용의 편리함을 증대할 수 있다.

RESTful API

RESTful API는 REST API와 같이 독립적인 개념이 아니라
REST 하게 쓰는 것을 목적으로 한, 그리고 REST의 원리를 따르는 시스템 또는 서비스를 RESTful이란 용어로 지칭하는 것이다.

만약 CRUD의 기능을 모두 POST로 처리한다던지

GET을 조회 이외의 다양한 용도로 사용한다던지

URI에 리소스 외의 정보가 들어간다던지 한다면

이는 "RESTful" 하지 않다고 할 수 있겠다.

	기존 웹 접근 방식	RESTful API
URL	notice/delete?no=12	notice/12
Method	GET/POST	GET/POST/PUT/DELETE
URI	액션을 나타냄	처리하려는 자원 나타냄

	기존 게시판	RESTful API 게시판
글 목록	GET /notice/list	GET /notice
글 상세	GET/notice/list/{idx}	GET /notice/{idx}
글 등록	POST /notice/add	POST /notice
글 삭제	GET /notice/remove/{idx}	DELETE /notice/{idx}
글 수정	POST /notice/modify/{idx}	PUT /notice/{idx}

참고 사이트

[AWS] https://aws.amazon.com/ko/what-is/api/

https://rebeccacho.gitbooks.io/spring-study-group/content/chapter16.html

https://velog.io/@se_bb/Spring-Framework-10%EA%B0%95-RESTful-API

https://rimkongs.tistory.com/221

https://maenco.tistory.com/entry/Spring-MVC-Request-Mapping-%EA%B3%BC-REST-API-%EC%84%A4%EA%B3%84

https://maenco.tistory.com/entry/HTTP4-API-%EA%B7%B8%EB%A6%AC%EA%B3%A0-REST-API

https://bmangrok.tistory.com/entry/Spring-%EC%84%9C%EB%B2%84%EC%97%90%EC%84%9C-%EB%8B%A4%EB%A5%B8-%EC%84%9C%EB%B2%84%EC%9D%98-Rest-API-%EC%9A%94%EC%B2%AD-%EB%B0%8F-%EC%9D%91%EB%8B%B5-%EB%B0%9B%EA%B8%B0

https://colinch4.github.io/2021-06-07/restful/

https://bentist.tistory.com/37

참고 영상

https://www.youtube.com/watch?

[API란 무엇인가? | 초보자를 위한 쉬운 개념 정리!!]

참고 서적

최범균 저,"초보 웹 개발자를 위한 스프링5 프로그래밍 입문", 가메출판사, 2023.04

yunSeok

다음 포스트