0. 들어가기 전
REST API 알아요? 그럼요... 아닐수도?나는 웹을 무작정 따라하며 시작했다. "REST API를 사용해봅시다. 이럴때는 GET method를 써야하고, 요럴때는 POST method를 써야합니다."라는 강의를 보며 어떠한 method가 적절할지는 감을 잡은것 같았다. 근데 누가 물어봤다.
REST API가 뭐에요?
그 뭐냐 GET... GET 같이 알아볼까요?
1. 정의
REST가 약자였어..? REST가 뭐에요?
jojoo: 그 뭐냐 GET...
파파고: 휴식?
aws: Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처입니다. REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌습니다. REST 기반 아키텍처를 사용하여 대규모의 고성능 통신을 안정적으로 지원할 수 있습니다. 쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있습니다.
REST: API를 설계하는 아키텍처 스타일 중 하나
API 개발자는 여러 아키텍처를 사용하여 API를 설계할 수 있습니다. REST 아키텍처 스타일을 따르는 API를 REST API라고 합니다. REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 합니다. RESTful API라는 용어는 일반적으로 RESTful 웹 API를 나타냅니다. 하지만 REST API와 RESTful API라는 용어는 같은 의미로 사용할 수 있습니다.
REST API: REST 아키텍처 스타일을 따르는 API
RESTful API: REST 아키텍처를 구현하는 웹 서비스
그럼 REST 아키텍처 스타일은 무엇일까??
2. 규칙 (REST STYLE)
무엇이 REST일까요?6가지 규칙을 준수하는 것을 REST 아키텍처라고 합니다.
a. Uniform Interface (인터페이스 일관성)
b. Stateless (무상태)
c. Cacheable (캐시 처리 가능)
d. Layerd System (계층화)
e. Server-Client (클라이언트/서버 구조)
a. Uniform Interface
여기가 그 GET POST PUT 그런겁니다.The uniform interface constraint defines the interface between clients and servers. It simplifies and decouples the architecture, which enables each part to evolve independently.
어우 무슨 말이죠?
파파고: 균일한 인터페이스 제약 조건은 클라이언트와 서버 간의 인터페이스를 정의합니다. 아키텍처를 단순화하고 분리하여 각 부분이 독립적으로 발전할 수 있도록 합니다.
다시말해, 클라이언트와 서버는 HTTP에 URI resource, CRUD, JSON등을 통해서 아키텍처를 단순화하여 균일한 인터페이스(Uniform Interface)를 각자 맞추어(independently) 통신을 합니다.
이 균일한 인터페이스는 4가지의 규칙을 따르고 있습니다.
ㄱ. identifying resoucres
REST API는 클라이언트가 요청에 포함된 URI를 통해 리소스(resource)를 식별할 수 있도록 해야 한다.
말 그대로 URI가 식별가능해야 합니다.
ㄴ. manipulation through representations
클라이언트가 이해하고 조작할 수 있는 형식으로 보내야한다. 다시말해, 클라이언트의 요구에 맞게 서버는 리소스를 보낼수 있어야 한다.
- ex) URL: /cars/123에 text/plain or applicaiont/json 등등 클라이언트의 요청에 맞는 리소스를 보내줌
처음 알았네요. 이것을 개발자가 해야하는지 알아서 해주는지는 문제가 발생하면 추가적으로 글을 쓰겠습니다.
ㄷ. self-describing messages
리소스의 표현은 리소스를 처리하는 방법에 대한 정보와 함께 클라이언트에 반환되어야 한다.
- ex) HTTP GET, POST, PUT ...
넵..!
ㄹ. HATEOAS (Hypermedia As The Engine Of Application State)
해당 리소스의 표현을 반환(return)하는 것 외에도, 리소스 또는 API에 상호 작용하는 방법 혹은 정보가 있어야 한다.
- ex) HATEOAS를 안한 반환
{
"carId" : 123,
"color" : yellow
}- HATEOAS를 적용한 반환
{
"carId" : 123,
"color" : yellow,
"links" : [
{
"rel" : "self",
"href" : "http://jojoo/cars/123"
}, ...
]
}즉, 그 리소스에 관한 추가적인 정보를 알수있게 "links"등을 추가적으로 리소스에 넣어줘야 한다.
대부분이 잘 안지키고 있는 것이라고 합니다. 저 역시 대부분입니다. HATEOAS를 알게 되었지만 필요성은 못 느껴서 사용하게 되면 추가적으로 글을 쓰겠습니다.
b. Stateless
stateless는 서버에 클라이언트의 상태 정보를 저장 하지 않은 것이라고 할수 있습니다. 서버는 클라이언트가 누구인지 아무것도 모르는 상태이고, 세션 상태(sesstion state)는 오로지 client가 알고 있습니다. 그래서 stateless는 세션을 독립적(session independe)으로 만듭니다.
c. Cacheable
캐싱(cashing)이 가능해야합니다. 몇가지 특징을 더 알아봅시다.
- GET은 default로 캐싱되어야 합니다.
- POST는 default로 캐싱은 안되지만 옵션을 통해 바꿀수 있습니다.
- PUT과 DELETE는 캐싱되지 않습니다.
d. Layerd System
REST allows you to use a layered system architecture where you deploy the APIs on server A, and store data on server B and authenticate requests in Server C, for example. A client cannot ordinarily tell whether it is connected directly to the end server or an intermediary along the way.
layerd system은 서버의 계층이 어떻게 되어있는지 클라이언트는 알수 없는 것입니다. 예를들면 클라이언트가 서버에 요청을 합니다. 그 서버가 계층, 캐싱, 로드벨런서 등등의 계층으로 구성되어도 요청, 응답에는 무관하며 클라이언트는 이 계층을 알수 없습니다.
e. Server-Client
Servers and clients may also be replaced and developed independently, as long as the interface between them is not altered.
파파고: 서버와 클라이언트 사이의 인터페이스가 변경되지 않는 한, 서버와 클라이언트는 독립적으로 교체되고 개발될 수도 있습니다.
출처
- https://restapilinks.com/
- https://berrrrr.github.io/programming/2019/11/03/restapi-uniform-interface/
- https://joomn11.tistory.com/26
- https://aws.amazon.com/ko/what-is/restful-api/
- https://www.restapitutorial.com/lessons/whatisrest.html#
- https://5equal0.tistory.com/entry/StatefulStateless-Stateful-vs-Stateless-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%99%80-HTTP-%EB%B0%8F-REST
0개의 댓글
