Stay hungry, Stay foolish

RESTful API 본문

카테고리 없음

RESTful API

Jake2 2021. 7. 11. 13:35

https://jake2.tistory.com/4

 

URI? URL? URN?

URL, URI 많이 들어 본 단어다 , 그리고 URI 가 URL 보다 더 큰 개념이다는것도 얼핏 많이 들어봤을 것이다. URI (Uniform Resource Identifier) / URL (Uniform Resource Locator) 그러면 차이점은 뭘까?? 서적..

jake2.tistory.com

에 이어서 

 

API를 RESTful 하게  작성하라

 

라는 말 많이 들어보지 않았나?

 

과연 RESTful 한 API 란 무엇일까.

 

우리가 앞에서 본 resource 즉 HTTP URI로 정의된 자원을 어떻게 한다(HTTP method + payload)는 내용을 정의하는 방식을 구조적으로 깔끔하게 만드는 것이다.

 

따라서 RESTful 한 API 는 그 자체만으로도 이 API 가 무엇을 의미하는지 어떠한 자료를 통신하는지 목적이 쉽게 이해가 된다.

 

예를 들어 나는 지금 특정 상품에 대한 (경험해보고싶어요, 경험해봤어요) 같은 상태와 댓글에 대한 좋아요를 나타내는 API 를 만들고 있다.

 

그리고 이 상품에 대한 상태(wish or done 으로 표기한다) 라는 테이블과, like 라는 테이블을 따로 만들었다.

 

├── comments
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── likes
│   ├── __init__.py
│   ├── __pycache__
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── manage.py
├── products
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── ratings
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── users
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── core.py
│   ├── migrations
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   ├── utils.py
│   ├── validation.py
│   └── views.py
└── watcu
    ├── __init__.py
    ├── asgi.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

위와같은 트리구조의 프로젝트이다. watcu 라는 프로젝트 아래 products, users, ratings, likes, comments 와같은 5개의 app 이 있다. 

 

그러고 여기서 내가 말한 상품의 상태나, 댓글의 좋아요에 대한 model 과 로직은 likes 라는 앱안에 들어있다.

 

따라서 RESTful 한 API 의 중요성을 몰랐을 때는 likes 안에 url 경로를 두고 http://서버주소/likes/<int:product_id>

 

이런식으로 작성 했을 것이다. 하지만 이러면?? 이게 좋아요/1 이라는게 좋아요의 id가 1인지 user id가 1인지 product_id가 1인지

 

누가 알겠는가, 따라서 RESTful 하게 작성하는 법은 정해진 규칙은 없지만, 

 

1. http:// 서버주소/products/<int:product_id>/status/<str:status>

와 같은 방법

 

2. http://서버주소/product/1?status=wish

 

와 같이 쿼리스트링을 이용하는 방법 두가지다

 

그러면 이렇게 query str 을 사용할지 path 를 사용할지 고민될때 기준은 무엇이 될까?

 

path parameter 를 사용할때 product 3번이 없다면 404 err 가 나온다.

 

그런데 우리가 무신사에서 검색을 한다고 생각해보자 @@라는 이름의 product를 검색했다. 혹은 필터링에 노란색에 신발에 300사이즈 이상에 벨벳소재의 등등 필터링을 추가했다 와 같은 기능에서 상품이 존재하지 않으면 그냥 상품이 없다 하고 끝이지 않나?

여기서 상품이 없다고 해서 err 를 response 할것 까지는 없다 이와 같은 filtering, sorting, searching 과 같은 경우에는 query parameter 를 이용해주는것이 좋고

나머지 경우 path parameter 를 이용해 주는 경우가 좋다.

 

RESTful 한 API 가 중요하다고 느껴지는 가장큰 이유 한가지는 개발은 혼자하는게 아니기 때문이다.

 

만약 개인프로젝트면 API 개똥같이 짜놔도 뭐가 중요하겠는가 나만 알아보면 되는데 하지만, 실제로 현업에서 사이즈가 큰 프로젝트라면??

 

BE, FE, Devops, QA, 기획, 디자이너 등 다양한 개발자 및 비개발자로 이루어진 조직에서 프로젝트가 진행될 것이다. 그렇다면 이들이 

 

봤을때 API 주소만 보고도 아 뭐구나 직관적으로 알게 작성하는것이 상당히 중요한 부분 중 하나일 것이라 생각된다.

 

 

Comments