RESTful API란?

RESTAPI 등장 배경

WEB (1991) - 팀 버너스리에 의해 월드 와이드 웹(www) 탄생
표현 형식을 HTML, 식별자를 URI, 정보들을 전송하는 방법으로 HTTP 프로토콜 사용
당시 HTTP 프로토콜 전송 방식을 여러 사람이 참여하여 설계를 하게 되었는데 그중 Roy Fielding도 참석

1994년 Roy Fielding HTTP 1.0 작업에 참여
HTTP 1.0이 나오기 전 월드 와이드 웹에서는 이미 HTTP는 전송 프로토콜로서 이용이 되고 있는 중
즉 이미 이 시점에는 전 세계에 수많은 웹 서버가 존재하고 있는 시기
HTTP를 적립하고, 명세에 기능을 더 하고 , 기존의 기능을 고쳐야 하는 상황
기존의 이미 구축되어 있는 웹 하고 호환성에 문제가 생기는 것을 어떻게 피할 것인가 문제 존재
고민 1 : “어떻게 하면 웹을 망가뜨리지 않고 HTTP를 발전시킬 수 있을까?”
고민 2: “웹의 장점을 어떻게 하면 최대한 활용할 수 있을까?”
그것에 대한 해결책으로 HTTP Object model 발표 → 4년 후 1998년 Representational State Transfer 이름 변경 → 2년 후 박사 논문 출간 (REST)
REST 논문 보기
1996년 기존에는 웹 상에서 사람이 읽는 문서만 주고 받았으나 이제 서버와 클라이언트가 데이터를 주고받을 일이 빈번해짐
그러면서 등장한 게 2000년 Microsoft 에서 원격으로 다른 시스템의 메서드를 호출할 수 있는 XML-RPC 프로토콜을 만듦
이후 soap(Simple Object Access protocol)로 이름 변경
Salesforce → 인터넷에서 거의 최초의 API를 공개 →SOAP 이용

SOAP과 REST의 첫 느낌

그러면서 아래와 같은 결과를 초래

SOAP 은 갈수록 인기가 떨어지고 Rest는 점점 인기가 올라가게 됨
2006년 AWS가 자사 api의 사용량의 85%가 REST임을 밝혔고 2010년 Salesforce 마저 REST API를 지원

API 란 무엇인가

API란 Application Programing interface의 약자입니다.

인터페이스란 상호 간에 소통을 위해 만들어진 접점을 의미합니다.

즉 API란 한 프로그램에서 다른 프로그램으로 데이터를 주고받기 위한 방법을 뜻합니다.

사물과 사물, 사람과 사람 어떠한 서로 다른 두 개 이상의 것들이 소통하기 위한 방법입니다.

예시 1)

맥도날드에 햄버거를 주문하려고 키오스크 앞에 갔습니다.

많은 메뉴 중 세트 메뉴를 하나 고르고 주문하기를 눌렀습니다.

이때 키오스크 화면에 나타난 메뉴와 주문하기 버튼이 인터페이스에 해당합니다.

왜냐하면 키오스크의 화면을 통해 사용자와의 소통 역할을 하기 때문입니다.

이렇게 컴퓨터와 사람. 상호 간에 소통을 위해 만들어진 접점. 이것을 인터페이스라고 칭합니다.

주문하기를 누르면 점원에게 주문이 전송되고 방금 주문한 메뉴가 점원 포스기에서 출력됩니다.

이렇게 키오스크와 포스기 사이 즉 기계와 기계, 프로그램과 프로그램 사이에서 데이터를 주고받기 위한 방법(코드)을 API라고 부릅니다.

예시 2)

서버에는 API 즉 사용자에 요청에 대한 응답을 하는 어떠한 코드가 작성이 되어있고 아래와 같이 사용자가 요청을 합니다.

(GET 요청) www.ggultoons.com/webtoon/viewer?id=1000

서버에는 위와 같은 URL을 받으면 내부적으로 요청을 처리하는 어떠한 코드가 짜여 있습니다.

그럼 사용자가 해당 URL을 입력하면 서버에 작성된 API 즉 코드가 실행되게 됩니다.

API 구성 요소

어떤 요청을 보낼 지 요청 방식 (GET) 이 포함되어야 함
어떤 자료 요청을 할 것인가? → endpoint
파라미터 → URL(자원) 이외의 부가적인 정보

코드가 실행이 되면 서버는 웹툰에서 id가 1000번인 웹툰을 사용자에게 제공합니다.

다시 API에 대해 쉽게 정리해 보자면 API란 서버에 작성된 메뉴판(코드)이고 사용자는 메뉴판 중 특정한 메뉴를 골라서 서버에게 요청을 하면 서버는 사용자가 요청한 메뉴를 제공해 주는 것

API란 한 프로그램에서 다른 프로그램으로 데이터를 주고받기 위한 방법

REST란 Representational State Transfer 의 약자로 직역하면 ‘표현된(자원의) 상태 전송’ 입니다.

대체 무슨 말이지….

풀어서 설명하면 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고받는 것을 의미합니다.

즉 Rest API 란 응용프로그램 사이에서 정보를 주고받는 것에 대한 규칙으로 개발 방법론 중 하나입니다.

또 다른 말로 ‘분산 하이퍼 미디어 시스템(웹과 같은)을 위한 아키텍처 스타일’라고 합니다.

여기서 아키텍처 스타일이란 제약 조건의 집합으로 아래와 같이 제시된 제약 조건을 모두 지켜야 Roy Fielding이 말하는 REST를 따르는 API 즉 RESTful API 가 됩니다.

1️⃣ Client-Server

2️⃣ Stateless

3️⃣ Cache

4️⃣ Uniform Interface

5️⃣ Layered System

6️⃣ Code-On-Demand (optional)

REST API는 HTTP 스펙을 잘 따르는 것을 바탕으로 하기 때문에 먼저 HTTP가 무엇인지 알아본 후 위의 제약 조건을 후에 알아보겠습니다.

RESTAPI란?

REST API 란 REST 아키텍처 스타일에 부합하는 API
결국 REST란 위에서 살펴 보았 듯이 HTTP를 잘 사용하기 위한 API 아키텍처 중 하나
REST란 무엇인가

REST 구성 요소

1️⃣ 자원(Resource) - URI

모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재합니다.
자원을 구별하는 ID는 HTTP URI입니다.
클라이언트는 URI를 이용해 자원을 지정하고 해당 자원의 상태에 대한 조작을 Server에 요청합니다.

2️⃣ 행위(Verb) - Method

HTTP 프로토콜의 Method를 사용

3️⃣ 표현 (Representation of Resource)

클라이언트와 서버가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등
JSON, XML을 통해 데이터를 주고받는 것이 일반적
현재는 대부분 JSON 형식으로 데이터를 주고받음

REST의 제약 조건 및 특징

1️⃣ Server-Client (서버-클라이언트 구조)

클라이언트와 서버를 각각 독립적으로 분리하는 구조
자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client
- Server는 API를 제공하고 비즈니스 로직 처리 및 데이터 저장의 책임짐
- Client는 사용자 인증이나 context( 세션, 로그인 정보) 등을 직접 관리하고 책임짐
역할을 확실히 구분함으로써 서로 간의 의존성을 줄이고, 독립적인 발전 가능해짐

2️⃣ Stateless (무상태)

HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 가짐
Client의 context를 Server에 저장하지 않음
- 즉, 세션과 쿠키와 같은 context 정보를 신경 쓰지 않아도 되므로 구현이 단순
Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리
- 각 API 서버는 Client의 요청 만을 단순 처리
- 즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안 됨→ [예외 : DB에 의해 바뀌는 것은 허용]
Server의 처리 방식에 일관성을 부여하기 때문에 서비스의 자유도 UP
서버의 확장(scale out) 유리

3️⃣ Cache(캐시 처리 기능)

웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있음
- 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능 적용 가능.
- HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 구현
대량의 요청을 효율적으로 처리할 수 있음

4️⃣ Layered System (계층 구조)

REST Server는 다중 계층으로 구성될 수 있음
- 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조 변경 가능
- Proxy, Gateway와 같은 네트워크 기반의 중간 매체 사용이 가능
- 하지만 Client는 Server와 직접 통신하는지, 중간 서버와 통신하는지는 알 수 없음.
API 서버는 순수 비즈니스 로직을 수행

5️⃣ Uniform Interface (인터페이스 일관성) 🌟

URI로 지정한 Resource에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하며, 느슨한 결합 형태 가짐
즉, 특정 언어나 기술에 종속되지 않음

6️⃣ Code-On-Demand(optional)

'서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다’를 Code-On-Demand
javascript와 같은 코드를 클라이언트로 보내 실행될 수 있게 끔 하는 것을 의미

🤔 UniformInterface의 4가지 제약 조건

1 ) Identification of resources (자원의 식별)

자원이란?
- 이름을 지닐 수 있는 정보
- 개념적인 대상
- 예) 문서, 이미지, 실존 대상 등
자원은 객체 → 시간에 따라 생성, 변경, 소멸
서버에 존재하는 고유한 식별자로 URI를 사용해야 함
/members/100 → members(자원)

2 ) Manipulation of resources through representations (표현을 통한 자원의 조작)

표현 : 특정한 상태의 자원에 대한 표현
자원은 다양한 방식으로 표현 가능
예) 문서, 파일, 이미지, HTTP 메시지 등

GET /members/100 HTTP/1.1

HTTP/1.1 200 OK
Content-type: application/json
Content-length: 30

{"id":"test", "name":"김철수"}

서버는 member 100번(자원)의 현재 상태를 HTTP 메시지로 표현
Representaional State Transfer에 담긴 의미
- 특정 시점에 자원이 지니고 있는 상태를 특정한 형식으로 표현
- 그 표현을 서버와 클라이언트가 서로 주고받는 것이 표현된(자원의) 상태 전송 즉 REST를 의미함

3 ) Self-descriptive messages (자기 서술적 메시지)

요청 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있습니다.
가장 큰 특징으로 각 요청이 어떤 동작이나 정보를 위한 것 인지를 그 요청의 모습 자체로 추론이 가능하다는 것

4 ) HATEOAS(hypermedia as the engine of application state)

hypermedia as the engine of application state의 약자
‘애플리케이션 상태는 Hyperlink를 이용해서 전이가 가능해야 한다’라는 뜻

오늘날 우리가 개발한 REST API가 진짜 REST API가 아닌 이유는 대체로 UniformInterface의 3, 4번의 제약 조건을 따르지 않기 때문에 진정한 REST API라고 하지 않습니다.

🚫 대부분 지켜지지 않고 있는 Self-descriptive messages

1️⃣ Self-desciptive messages?

말 그대로 메시지가 스스로 설명되어야 한다는 것
즉 메시지의 모든 요소는 메시지만 보고도 그 뜻을 알 수 있어야 한다는 것을 의미

{"id": 1, "title" : "안녕하세요"}

위 메시지를 통해 구체적인 내용을 알아보겠습니다.

서버로부터 위의 응답을 받았지만 해당 응답의 상태에 대해서 명시되어 있지 않아 해당 리소스의 상태를 알 수 없습니다.

그러므로 상태를 명시해줘야 합니다.

HTTP/1.1 200 OK

{"id": 1, "title" : "안녕하세요"}

응답을 명시하면서 사람은 대략 id가 1이고 title은 ‘안녕하세요 네’ 하면서 알 수 있지만 기계는 이해하지 못합니다.

어떠한 형식으로 작성된 정보인지 모르기 때문이죠.

그러므로 Content-type을 JSON으로 명시해서 클라이언트가 해석할 수 있게 끔 해야 합니다.

HTTP/1.1 200 OK
Content-type : application/json

{"id": 1, "title" : "안녕하세요", "name": "김땡땡"}

이렇게 상태, 형식, 응답 body의 내용을 명시하였습니다.

오늘날 우리가 사용하는 대부분의 API의 응답 형태가 이러한데요.

이렇게 까지만 명세가 되어있으면 과연 필딩이 주장한 self-descriptve 만족하는 것일까요?

그렇지 않습니다.

왜냐하면 이 메시지만 보아서는 title 이 무엇에 해당하는 title 인지 name은 어떤 것에 name을 말하는 것인지 충분히 설명되고 있지 않기 때문입니다.

그러면 이러한 id, title, name과 관련된 설명 즉 명세는 어떻게 할 수 있을까요?

2️⃣ Self-descriptive messages 방법

1) Media type 정의

IANA 등록 이미지

미디어 타입을 하나 정의한다.
미디어 타입 문서를 작성한다. 이 문서에 title은 무엇이고 name은 무엇인지 의미를 정의한다.
IANA에 미디어 타입을 등록한다. 이때 만든 문서를 미디어 타입의 명세로 등록한다.
이제 이 메시지를 보는 사람은 명세를 찾아갈 수 있으므로 이 메시지의 의미를 온전히 해석할 수 있다.

매번 media type을 정의하고 등록해야 하기 때문에 번거롭고 쉽지 않음
IANA 미디어 타입 등록하러 가기

2) Profile link relation 이용 - Link header에 명세를 확인할 수 있는 링크를 넣어 응답

HTTP/1.1 200 OK
Content-type : application/json
Link : <https://https://www.exmaple.org.docs/contents>; rel="profile">

{"id": 1, "title" : "안녕하세요", "name": "김땡땡"}

title은 무엇이고 name은 무엇을 의미하는지 명세를 작성한다.
Link 헤더에 profile relation으로 행당 명세를 링크한다.
메시지를 보는 사람은 명세를 찾아갈 수 있으므로 이 문서의 온전한 의미를 해석할 수 있다.

단점
- 클라이언트가 Link 헤더(RFC 5988)와 profile(RFC 6806)을 이해할 수 있어야 함
- Content negotiation 할 수 없음

3️⃣ Self-descriptive 이점

서버나 클라이언트가 변경되더라도 오고 가는 메시지는 언제나 self-descriptive 하므로 언제나 해석이 가능

🚫 대부분 지켜지지 않고 있는 HATEOAS

1️⃣ HATEOAS?

hypermedia as the engine of application state의 약자
‘애플리케이션 상태는 Hyperlink를 이용해서 전이가 가능해야 한다’라는 뜻

여기서 말하는 상태의 전이라는 말은 무슨 말일까요?

예시를 통해서 살펴보겠습니다.

네이버 메인을 요청을 하면 다음과 같은 화면이 나타납니다.

그럼 여기서 사용자는 다음 행동으로 어떤 것을 할 수 있을 까요?

로그인
메일로 이동
카페로 이동
블로그로 이동

위와 같은 다음 상태로의 전이가 있을 수 있는데요.

URL을 통해 응답받은 HTML에는 이러한 상태 전이에 대한 명세가 a태그로 다음과 같이 되어있습니다.

HTTP/1.1 200 OK
Content-Type: text/html
<html>
<head></head>
<body>
<a href="www.naver.com/login">로그인</a>
<a href="www.naver.com/mail">메일</a>
<a href="www.naver.com/cafe">카페</a>
<a href="www.naver.com/blog">블로그</a>
<a href="www.naver.com/shop">쇼핑</a>
</body>
<html>

이처럼 HTML 은 HATEOAS를 만족한다고 볼 수 있습니다.

그럼 json 은 어떨까요?

HTTP/1.1 200 OK
Content-type : application/json

{"id": 1, "title" : "안녕하세요", "name": "김땡땡"}

보통 위와 같이 자원에 대한 상태 값들만 넘겨주기 때문에 HATEOAS를 만족하지 못합니다.

그럼 어떻게 하면 HATEOAS를 만족할 수 있을 까요?

2️⃣ HATEOAS 달성 방법

1) HTTP 헤더 사용

Link, Location 등의 헤더로 링크를 표현
- Json 도 selef-descriptive에서 사용한 Link 헤더를 사용할 수 도 있고 아래와 같이 응답 본문에 넣어 줄 수 도 있습니다.

GET /contents HTTP/1.1
Content-Type : application/hal+json
Location : /contents/1000
Link : </contents/>; rel="collection"

{"id": 1, "title" : "안녕하세요", "name": "김땡땡"}

위와 같이 링크를 응답에 다음 상태 전이에 대한 링크를 명세함으로써 HATEOAS를 만족할 수 있습니다.

2) data에 다양한 형식으로 하이퍼링크 표현

아래와 같은 Content-Type으로 data에 하이퍼링크를 표현
아래와 같은 JSON 형식으로 하이퍼링크를 표현하는 명세를 활용
- JSON API
- HAL
- UBER
- Siren
- Collection + json
HAL Json 활용 - Hypertext Application Language란?
- Hypertext Application Language로 JSON, XMl 코드 내의 외부 리소스에 대한 링크를 추가하기 위한 특별한 데이터 타입
- application/hal+json
- application/hal+xm
- application/hal+json 타입을 이용한다면 쉽게 HATEOAS 달성 가능

GET /contents HTTP/1.1
Host : example.org

HTTP/1.1 200 OK
Content-Type : application/hal+json
Link : <https://https://www.exmaple.org.docs/contents>; rel="profile">
{
"data": { // HAL JSON의 리소스 필드
"id": 1000,
"name": "게시글 1",
"content": "HAL JSON을 이용한 예시 JSON"
},
"_links": { // HAL JSON의 링크 필드
"self": {
"href": "http://localhost:8080/v1/api/contents/1000", // 현재 api 주소
"action" : "GET"
},
"detail": {
"href": "http://localhost:8080/docs#query-article", // 상세 페이지 주소
"action" : "GET"
},
"modify": {
"href": "http/localhost:8080/v1/api/contents/1000", // 콘텐츠 수정 주소
"action": "PUT"
},
"comment": {
"href": "http://localhost:8080/v1/api/contents/1000/coments", // 댓글 목록 주소
"action": "GET"
}
}
}

3️⃣ HATEOAS 이점

Client 사이드에서 하이퍼 링크를 사용하여 다음 상태를 결정할 수 있으므로, URI 수정이 발생하더라도 Client 사이드의 수정은 불필요하게 됨
- 예시) 상세 보기 엔드 포인트가 /v1/api/contents/detail/{idx}로 변경되어도 기존에 응답에 링크된 detail을 사용한다면 클라이언트 부분에서 변경할 부분은 없음
API 버전을 명세하지 않아도 됨
링크 정보를 동적으로 바꿀 수 있음
링크를 통해서 상태 전이가 쉽게 가능
링크에 대한 정보가 바뀌어도 클라이언트에서 대응이 필요치 않음

RESTful API Naming 규칙

1️⃣ 리소스 표현은 명사를 사용 - [URI는 명사]

리소스는 행위가 아니라 객체이므로 명사로서 구분
아래와 같은 동사 사용 X

/getAllUsers
/getUserById
/createNewUser
/updateUser
/deleteUser

단 해결하기 어려운 추가 프로세스 실행은 동사를 직접 사용
- GET 또는 POST 시 → 컨트롤 URI라고 함
- 예) POST /orders/{orderId}/start-delivery (컨트롤 URI)
Document , Collection 개념으로 단수 명사, 복수 명사 적절히 활용
- Document - 단일 개념(파일 하나, 문서 하나, 하나의 객체 등)
- Collection - 복수 개념(문서들의 집합, 객체들의 집합 등)
Collection과 Document는 모두 리소스라고 표현할 수 있으며 URI에 표현됨
- 아래 예시에서 news, sports는 Collection에 해당하여 복수 명사, baskeball, 100 은 Document에 해당하여 단수 명사

http://api.example.com/news/sports/basketball/100

2️⃣ 계층 관계 표현은 ‘/’를 사용

http://api.example.com/contents
http://api.example.com/contents/{idx}
http://api.example.com/contents/{idx}/comments
http://api.example.com/contents/{idx/comments/{commentIdx}

3️⃣ 마지막 문자로 ‘/’ 사용 X

https://api.example.com/members/ (X)
https://api.example.com/members (O)

4️⃣ 가독성을 위해 ‘-’ 하이픈을 사용하고, ‘_’ 언더바는 사용 X

https://api.example.com/orders/{orderId}/start_delivery (X)
https://api.example.com/orders/{orderId}/start-delivery (O)

5️⃣ 소문자를 사용하고 대문자는 사용 X

Schem과 HOST는 대소문자 구별이 없고 이 외에는 대소문자가 구별되기 때문에 섞어 썼을 경우 자원 식별이 쉽지 않음

http://api.example.org/my-folder/my-doc (1)
HTTP://API.EXAMPLE.ORG/my-folder/my-doc (2)
http://api.example.org/My-Folder/my-doc (3)

6️⃣ HTTP 응답 상태 코드 사용

클라이언트는 해당 요청에 대한 실패, 처리 완료 또는 잘못된 요청 등에 대한 피드백을 받아야 한다.
상태 코드 MDN 문서 → MDN 문서 보기

HTTP/1.1 200 OK
HTTP/1.1 201 Created
HTTP/1.1 400 Bad Request
HTTP/1.1 404 Not Found

7️⃣ 파일 확장자 사용 X

http://api.example.org/restapi/220/photo.jpg(X)

8️⃣ 필터를 위해 쿼리 파라미터 사용

http://api.example.com/contents?page=1&recordSize=10
http://api.example.com/search?keyWord=hello
http://api.example.com/weather?region=seoul&date=20230908

9️⃣ 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현

REST API 장단점

장점

유지보수 용이성
- 메시지를 읽는 것만으로도 메시지가 의도하는 바를 명확하게 파악 가능
- 자원에 대한 명확한 URI 사용으로 쉽게 이해 가능 - 가독성
확작성 : 서버와 클라이언트가 분리되어 서로 간의 의존성이 낮아 확장이 용이함
재사용성 : HTTP 프로토콜 기반으로 별도의 인프라 구축이 필요하지 않음
보안성 : 플랫폼에 독립적
캐시 : 서버 측의 부하 분산 가능

단점

HTTP 프로토콜에 의존
API의 문서화 등 추가 작업 필요
URI 설계가 복잡할 수 있다
Overfetching
- REST API는 항상 전체 데이터 세트를 반환
- 즉 클라이언트가 필요로 하지 않는 추가 데이터까지 서버로부터 받아 오는 것을 의미
- 예시 ) 사용자의 휴대폰 번호를 받아 오려는 상황
- /member/100 endpoint 요청 시 사용자의 휴대폰 번호뿐 아니라 이름, 나이, 주소 등 수많은 데이터가 함께 불러와 짐
- 불필요한 데이터를 받아 오므로 네트워크 사용량과 처리 시간 낭비
- 성능적인 이슈가 있을 경우 개발자는 필요로 하는 데이터마다 각각의 API 개발해야 함
Underfetching
- 클라이언트가 필요한 데이터를 한 번의 요청으로 가져올 수 없어 여러 번의 추가 요청이 필요한 상황을 의미
- 예시 ) 사용자의 구매 내역과 사용자 개인 정보를 받아 오려는 상황
- 사용자의 개인 정보는 /members/100 endpoint 호출
- 사용자의 구매 내역은 /members/100/purchase endpoint 호출
- 필요한 데이터를 가져오기 위해 여러 번의 요청이 필요하므로 성능 저하가 발생할 수 있음

→ 이러한 Overfetching과 Underfetching의 개선 Graph QL (Graph QL이란)

정리

오늘날 대부분의 REST API는 사실 REST를 따르지 않고 있다.
REST의 제약 조건 중 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못한다.
REST는 긴 시간에 걸쳐 진화하는 웹 애플리케이션을 위한 것이다.
REST는 심플하고 쉬워 보이지만 Fileding이 말하는 RESTful API를 구현하기란 사실 복잡하고 어렵다.
REST스타일의 HTTP API가 대다수
결국 중요한 건 최대한 stateless 하게 설계하여 서버 확장에 용이하게 하는 것이 중요
오픈 API가 아닌 사내에서 쓰는 API의 경우 API의 명세가 문서로 잘 정리되어 있고, 의미가 명확한 URI 설계를 한다면 fileding이 말하는 RESTful API는 굳이 따를 필요 없을 것이라 생각

참고

저작자표시 비영리 변경금지 (새창열림)

'HTTP' 카테고리의 다른 글

HTTP란? (0)	2024.03.29
OpenFeign(MSA CURL) (0)	2024.03.21
(HTTP)인터넷 네트워크 (0)	2022.05.23