개발지식 먹는 하마 님의 블로그

REST API와 RESTful API 본문

Web

REST API와 RESTful API

devhippo 2025. 3. 20. 16:27

API

애플리케이션이 서로 통신할 수 있도록 해주는 인터페이스이다.

문서 양식이라고 생각하면 이해하기 쉽다.
이렇게 요청서를 작성해서 넘겨주면 그에 따라서 필요한 걸 드릴게요!
라고 양식에 대한 규칙과 명령어를 정의한 것이다.


📌 REST (REpresentational State Transfer) = 자원의 표현에 의한 상태 전달

자원(데이터)을 이름으로 구분, 해당 자원의 상태(데이터 요청 시점의 자원 상태)를 주고받는 모든 것을 의미한다.

HTTP Method로 CRUD Operation을 적용하는 것을 Rest라 칭한다.

🟩 구성 요소

자원 : URI (URL + URN)
표현 : 데이터를 주고 받는 형태, JSON, XML
행위 : HTTP 프로토콜 Method

GET 정보 요청
POST 정보 입력
PUT 정보 업데이트 (데이터 전체를 바꿀 때)
PATCH 정보 업데이트 (데이터 일부만 바꿀 때)
DELETE 정보 삭제 (안전성 문제로 대부분 비활성화)

 

📌REST API

REST의 특징을 기반으로 서비스 API를 구현한 것
각 요청이 어떤 동작이나 정보를 위한 것인지를 요청의 형태로 추론이 가능하다.

🟩 REST API 디자인 가이드 

  1. URI는 정보의 자원을 표현해야 한다.
  2. 자원에 대한 행위는 HTTP Method로 표현한다.
    행위는 URI에 포함하지 않는다.

🟩 REST API 설계 규칙

  • 소문자, 복수명사, 하이픈(-) 사용
  • /로 계층 관계를 표현 (마지막에는 사용해선 안된다.)
  • HTTP 응답 상태 코드 사용 (오류에 대한 피드백)
  • CRUD 함수명 사용하지 않음
  • 파일확장자는 포함하지 않음
  • 정렬, 필터링, 페이징은 신규 API 제작이 아닌 Query Parameter를 사용한다.

📌RESTful API

REST의 원리를 따르는 것을 RESTful 하다고 한다.

 

💡 REST API와 RESTful API의 차이

RESTful API는 REST 아키텍처의 모든 제약 조건을 엄격히 따른다.
반면, REST API는 융통성있게 일부 원칙만 따를 수도 있다.

따라서 모든 RESTful API는 REST API가 될 수 있지만, 반대의 경우는 불가하다.

 

🟩 Restful API 설계 시 고려사항

1. Consumer first
    소비자(또다른 시스템, 개발자) 입장에서 간단하고 직관적인 API를 설계해야 한다.

2. Make best use of HTTP
    HTTP Method 와 Request, Response, Header와 같은 HTTP의 장점을 살려서 개발해야 한다.

3. 성숙도 모델 Level2 이상으로 설계.

4. Response Status
    각각의 API 요청에 따라서 적절한 HTTP 상태코드가 전달되어야 한다.
    왜 실패하고 성공 하였는지 함께 반환시켜주어야 한다.

5. No secure info in URI
    URI 에는 사용자의 정보를 포함해서는 안된다.

6. Use plurals
    제공하는 데이터에 복수형태로 쓰는것이 일반적이다.

7. User nouns for resources
    모든 리소스는 가능하면 동사가 아닌 명사형태로 표시한다.
    API URI 만 보고도 어떠한 API 인지 파악할 수 있는 것이 좋다.

8. For exceptions - define a consistent approach
   일괄적인 엔드포인트를 사용하는것이 좋다.

 

🟩 성숙도 모델

레벨  
Level 0 URL만 매핑한 놓은 상태
Level 1 외부 공개 리소스에 대해 의미있는 URL로 표현
HTTP 별로 서비스를 구분하여 사용하고 있지는 않음
GET, POST로 대부분 요청을 처리하고 에러를 반환한다.
Level 2 - 리소스의 용도와 상태에 따라 HTTP Methods에 맞게 CRUD 설계


- HTTP 의 메소드를 이용하여 리소스의 상태를 구분하여 서비스하면 비슷한 URI라도 메서드에 따라
  다른 형태의 서비스 제공 가능
Level 3 HATEOAS (Hypermedia As The Engine Of Application State)

회원 가입 후 수정 및 조회 등은 어떻게 하는 지, 다음 단계로 진행할 수 있는 또 다른 리소스 정보의 종류 등을 알려주는 기능

- 데이터를 가지고 다음 작업에서 어떤 작업을 할 수 있는지 상태 정보를 함께 넘겨준다
- 클라이언트 측에서 서버가 제공하는 서비스를 일일이 찾는 수고를 겪지 않아도 됨
- 엔드포인트만 가지고 있으면 서버가 제공할 수 있는 다음, 그 다음 URI를 알 수 있다.

 

'Web' 카테고리의 다른 글

DTO (Data Transfer Object)  (0) 2025.03.31
웹 서비스 구조 및 흐름을 비유와 함께 이해하기  (0) 2025.03.20
HTTP Message  (0) 2025.03.18
TCP와 UDP  (0) 2025.03.17
API 간략 정리  (0) 2025.02.17