일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
- API
- 노마드코드
- 재태크
- transaction
- 레일즈
- 레일즈 캐시
- Rails
- 노개북
- CU
- iamport
- trouble shooting
- 아임포트
- Watcha pedia
- HTTP
- redis
- 노마드코더
- Race Condition
- 북클럽
- 투자
- memcached
- 사업
- 주식
- Python
- Cache
- django
- restful
- 경제
- rails cache
- redis transaction
- Today
- Total
Stay hungry, Stay foolish
RESTful API 본문
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 주소만 보고도 아 뭐구나 직관적으로 알게 작성하는것이 상당히 중요한 부분 중 하나일 것이라 생각된다.