REST API & RESTful API

seyong·2021년 12월 5일
0
post-thumbnail

REST API 란 이전 포스트에서 작성한 REST의 원리를 따르는 API를 의미한다. REST API를 올바르게 설계하기 위해서는 지켜야 하는 몇가지 규칙이 있으며 해당규칙을 알아보자.

간단한 기본 배경지식 알고 넘어가기

URI (Uniform Resource Identifier)

- 해당 사이트의 특정 자원의 위치를 나타내는 유일한 주소
- Ex) https://finance.naver.com/login ⬅
      https://finance.naver.com/news  ⬅

- HTTP Method
	- HTTP request가 의도하는 action을 정의한 것

- Payload
	- HTTP request에서 server로 보내는 데이터 (body)

REST API 란?

REST API는 REST(REpresentational State Transfer) 아키텍처 스타일의 디자인 원칙을 준수하는 API이다. 이러한 이유 때문에 REST API를 종종 RESTful API라고도 한다.



REST API의 정의

  • REST의 특징을 기반으로 서비스 API를 구현한 것

  • 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 어플리케이션을 여러 개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 기업 대부분은 REST API를 제공한다.


REST API의 특징

  • REST API의 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 것이다.

  • 프론트엔드/백엔드 간의 통신을 좀 더 원할하게 할 수 있는 API

  • 좀 더 직관적이고 알아보기 쉬운 API

  • 제 3자의 입장에서 봤을때 보다 직관적임을 알수있음

  • 전 세계에서 가장많이 쓰이는 JSON 형태로 주고받는 API

  • REST API는 모든 개발자들이 접근하기 쉽고, 쉽게 사용할 수 있는 API이다.


REST API 디자인 가이드

REST API 설계 시 가장 중요한 항목은 다음의 2가지로 요약할수있다.

    1. URI는 정보의 자원을 표현해야 한다.
    1. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현한다.
    • 행위(Method)는 URI에 포함하지 않는다.

REST API의 설계 규칙 및 예시

1. URI 정보를 명확하게 표현해야 한다.

  • resource는 명사를 사용한다.
Ex) GET/user (X) ➡ GET/users/1 (O)
  • 대문자보다는 소문자를 사용하여야 한다.
Ex) http://sy1004.com/Running/ (X)
    http://sy1004.com/run      (O)
  • 아래 예시와 같은 동사를 사용하지 않는다.
    • /getAllUsers (X)
    • /getUserById (X)
    • /createNewUser (X)
    • /updateUser (X)
    • /deleteUser (X)

2. 마지막에 슬래시를(/)를 포함하지 않는다.

Ex) http://sy1004.com/test/ (X) 
    http://sy1004.com/test  (O)

3. 언더바 대신 하이폰을 사용한다.

Ex) http://sy1004.com/test_post  (X) 
    http://sy1004.com/test-post  (O)

4. 파일확장자는 URI에 포함하지 않는다.

Ex) http://sy1004.com/photo.jpg  (X) 
    http://sy1004.com/photo      (O)

5. 행위를 포함하지 않는다.

Ex) http://sy1004.com/delete-post/1 (X) 
    http://sy1004.com/post/1        (O)

6. resource에 대한 행위를 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

  • URI에 HTTP Method가 포함되서는 안된다.
Ex) GET delete/user/1  (X) 
    DELETE /users/1    (O)
  • URI에 동사가 포함되서는 안된다.
Ex) GET /user/show/1 (X) 
    GET /users/1     (O)

Ex) POST insert/user/2  (X) 
    POST /users/2       (O)

7. resource 사이에 연관 관계가 있는 경우

  • /리소스/고유ID/관계 있는 리소스
    Ex) GET / users/{user_id}/porfile



REST API의 설계규칙을 잘 지킨 사진 예시

  • 아래 사진은 REST API의 설계 규칙을 잘 따른 예시 사진이다.





RESTful API 란?

RESTful이란 REST의 원리를 따르는 시스템을 의미한다. 하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아니다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며,

모든 CRUD 기능을 POST로 처리 하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있다.

RESTful API의 장점과 단점

장점

➡ self-descriptiveness, RESTful API는 그 자체만으로도 API의 목적이 쉽게 이해된다.

단점

➡ 표준규약이 없어, 안티패턴으로 작성되는 경우가 흔하다.

안티패턴 : 실제 많이 사용되는 패턴이지만 비효율적이거나 비생산적인 패턴




. Reference
https://www.ibm.com/kr-ko/cloud/learn/rest-apis
https://ko.wikipedia.org/wiki/REST

profile
# 불편함을 편리함으로 바꾸고싶은 주니어 Back-end 개발자

0개의 댓글