[CS/API] RESTful API 란? +URI, HATEOAS

2024.12.14 - [💻/CS] - [CS/ API] API 란?

[CS/ API] API 란?

 

저번에 API의 개념에 대해 간략히 정리 했다.
 
 
이번에는 REST API, 정확하게는 RESTful API에 대해 정리해보자. ☺️

 

 
 

1. RESTful API 란?

RESTful API는 다양한 형식들 중 오늘날 가장 널리 사용되는 것이다.
 
RESTful API는 A가 어떤방식으로 데이터를 요청하면, B가 어떤 방식으로 응답할 지 지정해놓은 다양한 형식 중 하나이다.
 
왜 이 방식의 API가 인기가 많고 좋은 방식이라는 것일까?
 
어떠한 인터페이스와 서버가 RESTful API 형식의 API를 통해 소통을 한다고 하면,
이들은 크게 'CRUD'방식으로 작동한다.
 
Create : 정보를 생성해서 넣는 것 (정보추가)
Read : 조회하는 것
Update : 현존하는 특정 정보를 변경하는 것
Delete : 특정 정보를 삭제하는 것
 
 
CRUD에 대한 자세한 내용은 이전의 게시물을 참고하자. ☺️

2024.10.31 - [💻/Server] - [서버] CRUD 란? + CRUD와 REST

[서버] CRUD 란?  + CRUD와 REST

 
 
 
 
 
 

2. RESTful API 특징1-  URI

 

다시 RESTful API로 돌아와서,
이 4가지 작업을 위한 요청(Request)들을 RESTful한 요청으로 보내기 위한 🔍URI을 작성해보면 아래와 같다.

---

🔍
URI : Uniform Resource Identifier, 통합자원식별자
인터넷에 있는 자원을 나타내는 유일한 주소. 인터넷에 존재하는 각종 정보들의 유일한 이름이나 위치를 표시하는 식별자이다.
 
URL: Uniform Resource Locator
웹주소이다. 컴퓨터 네트워크 상에서 리소스가 어디있는지 알려주기 위한 규약이다.
 

---

 
 
 

URI 예시

 

다시 위의 API를 요청한 형식을 살펴보면,
모두 HTTP 프로토콜을 사용해 작업을 요청하고 있다.
 
HTTP는 RESTful API의 필수요소는 아니지만, RESTful API의 조건을 구현하기에 용이함으로,
현업에서는 주로 HTTP가 사용된다고 한다.
 
위의 예시에서
v1은 api의 버전정보를 나타내고 있다.
각 uri의 분홍글씨의 books는 각 요청이 어떤 데이터에 관한 것인지를 명시하고 있다.
 
즉,
만약 API 가 REST원칙을 잘 지켜 만들어졌다면
각 요청의 메서드(REST)와 URI 자체가 그것의 목적을 명확히 나타내기 때문에
개발자는 다른 팀과 협업을 하거나, 어떤 API를 처음으로 사용해야할 때에도 새 API 의 사용법을 쉽게 익힐 수 있다. 
 
 
RESTful API에서의 요청과 응답에서는 구조화된 데이터표현이 가능하면서도 가벼운 JSON이 많이 사용된다.
(JSON에 대해서는 추후에 기회가 되면 정리할 예정이다.☺️)
 
 
 
 
각각의 URI 별로 어떤 정보를 나타내는지 몇가지 URI를 통해 알아보자.
 
 
CASE 1.
예시로 GET 방식으로 API를 요청하였다고한다면,
이는 도서 정보를 모두 불러달라는 것을 의미한다.
아래의 URI에서는 거기에 더불어 'status=available'이라는 조건을 명시했다.
이러한 조건을 명시함으로서 status가 available인 상태의 책들만 확인하도록 하는 것이다. 

 
 
 
CASE2.
실무에서는 URI에 페이지에 대한 조건을 넣어둠으로서
한 페이지에 10권씩 뜨게 해달라는 조건을 붙여
한 페이지내 표시될 데이터의 수를 제한하는데, 이는 데이터를 로드하는 과정으로부터 과부하를 방지한다.

 
 

CASE3.
PUT과 PATCH는 모두 Update에 해당한다.
 

PUT은 전부를 갈아 엎는다. 

 
반면, PATCH는 부분만 수정한다는 차이가 있다.

 
 
 

 
 

3.RESTful API 특징2 - HATEOAS

RESTful API에서 권장되는 또다른 원칙은 HATEOAS 이다.
Hypermedia
As
The
Engine
Of
Application State
 
이는 각 요청의 응답에, 가용한 다른 요청들의 정보를 포함시키는 것이다.
이 리소스에 대해 이러한 기능들도 이와 같이 요청할 수 있다고 첨부해주는 것이다!

HATEOAS 예시

이 링크 정보들을 통해 개발자는 API문서를 다 뒤져보지 않아도
다음에 어떤 요청을 보낼 수 있는지 볼 수 있으며,
이 부분의 API의 세부사항이 변경되더라도, 클라이언트는 이 정보를 참조하게 만들면 클라이언트의 코드를 고칠 필요도 없어지는 것이다.
 
각 API는 HATEOAS를 가지고 있으면 좋다.
 
 
 
 

4. RESTful API 특징3 - 응답의 상태코드

 
: 서버의 응답에는 요청을 처리한 결과를 알려주는 상태코드가 담겨온다.
 
2XX : Success
4XX : Client Error (URI가 잘못됨 or 권한 외의 요청을 함 . 즉, 클라이언트의 요청 잘못)
5XX : Server Error 
 
크게는 이렇게 구분할 수 있으며, 자세한 상태코드는 이전의 글을 참고하자.☺️

2024.10.29 - [💻/Network] - [HTTP] Http 상태 코드 (Http Status Code)

[HTTP] Http 상태 코드 (Http Status Code)

 

 
 
 

5. RESTful API 특징4- Stateless

또한 Restful API는 'Stateless' 특성을 가진다.
Stateless란 클라이언트의 상태 정보가 서버에 저장되지 말아야 한다는 것이다.
즉, 서버는 크라이언트에 대해 아무것도 기억하면 안된다는 것이다.
이 특성 때문에 클라이언트는 요청을 몇번째 반복해서 보내든지 간에, 필요한 내용을 매번 모두 포함하고 있어야한다.
 
 
클라이언트 : 아까 내가 요청했던거 다시 요청한다~ 해줘 ~~
서버 : 안됨! 다시 요청해주세요.
 
 
클라이언트와 서버는 서로를 기억해서는 안된다.하지만, 각각 본인이 어떤 요청을 보냈는지 또, 어떤 응답을 보냈는지, 어떤 응답을 받았는지는 기억해두는게 좋다. -> 캐싱(Caching)
 
클라이언트가 어떤 요청에 대한 응답을 본인에게 캐싱해두면, 같은 데이터가 필요할 때마다 요청을 보내지 않아도 되고,서버도 특정요청에 대해 응답한 것을 캐싱해두면, 같은 요청이 들어왔을때 또 DB에서 정보를 캐내지 않아도 된다는 것이다.
 
 
 
 
 
 
 
 
 
 
 
* 유튜브 얄팍한 코딩사전님- 영상 참고