일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 티스토리챌린지
- 애자일 싫타
- 개발 어렵당.ㅠ
- R2DBC Paging
- Armeria
- Ingress Controller Fake
- 7879
- save/update
- RedirectService
- 노드간 통신
- OIDC
- 월급루팡 일지
- pinpoint
- Loki 로그
- intellij
- reids
- hbase 저장공간 설정
- 플루터
- jsonMarshaller
- ㅉ때
- LPOS
- 오블완
- 핀포인트
- UnsupportedOperationException
- fake jwt
- nGinder
- formik
- 논블록킹 성능
- jar 배포
- pinpoint 2.5.3
- Today
- Total
대머리개발자
RESTful API 본문
RESTful API : API를 REST하게 만든 것이다.
그럼 REST 하다는 것은 뭐냐?
# 리소스명은 동사보다 명사를 사용 하구
# 자원에 대한 행위는 GET / POST / PUT / DELETE 표현 하구
...
좀 더 디테일한 규칙이 있지만 언급하지 않겠다. (https://sanghaklee.tistory.com/57)
뭐 암튼 위 규칙에 맞게 설계를 한다면 Rest한 API라고 한다.
개인적으로 restful 한 방식의 설계를 좋아하지 않는다.. 왜냐 현실적이지 않다.
남들 다 한다고 해서 무조건 할 이유가 없다. 스스로의 납득과 설계 이유가 확실하지 않는다면
심지어 KISA에서도 자원에 대한 행위로 PUT / DELETE 사용을 권고 하지 않는다. (보안상의 이유로)
고민의 발단은 아래와 같은 기능을 추가하려는데 있어 가장 바람직한 방식의 설계는..?
1-1. 로또 번호를 추천한다.
1-2. 과거 당첨된 번호를 가져온다.
2. 추천된 번호를 저장한다.
3. 전체 로또 번호를 조회한다.
4. 추천했던 번호를 조회한다.
5. 구매했던 번호를 조회한다.
코에 걸면 코걸이고 귀에 걸면 귀걸이다.
자기 논리만 있으면 된다. 즉 말 잘하는 놈이 이긴다. ㅎㅎ
1-1. GET /lotto-suggestion
1-2. GET /lotto/1070
2. POST /lotto
3. SEARCH /lotto-list
....
모든 행위를 담기에는 한계가 존재한다.
그리고 난!! 파라미터를 노출하는것을 별로 좋아 하지 않는다.
하악하악.. 그래프QL-Ful 로 가즈아!!
'개발이야기 > 개념' 카테고리의 다른 글
좀 더 deep 하게 쿠버네이트 구성해보자. (1) (0) | 2023.07.27 |
---|---|
Http 응답코드에 대한 설계 (0) | 2023.06.14 |
What the OIDC (0) | 2023.05.17 |
개발에선 "절대"는 없다. (0) | 2023.03.14 |
코딩컨벤션 (0) | 2023.03.04 |