34. TIL (Rest API)

1. restful api

api 시스템을 구현하기 위한 아키텍쳐(구조) 중에 가장 널리 사용되는 형식

☑️ api 시스템 구조 짜기, 우리가 만드는 모든 기능들
☑️ Representational State Transfer
: 웹상에서 사용되는 여러 리소스를 http url로 표현하고 그 리소스에 대한 행위를 http method로 정의하는 방식. 리소스를 어떻게 한다! (http method+payload)를 깔끔하게 표현
각종 데이터를 uri로 접근하여 어떠한 메소드를 사용해서 쓸 것인가?

• 장점 : api 자체로 목적이 쉽게 이해된다
• 단점 : 표준 규약이없어 비효율적(안티패턴)으로 작성되는 경우가 흔하다.

* 기본 개념 (확실히 알고 넘어가자! http의 개념들~)
☑️ URI (uniform resource identifier) : 해당 사이트의 특정 자원의 위치를 나타내는 유일한 주소
☑️ http method : http request가 의도하는 액션을 정의하는 것
☑️ payload : http request에서 서버로 보내는 데이터

2. 설계규칙

uri 정보를 명확하게 표현해야 한다. resource는 명사!

☑️ resource에 대한 http method
(여러데이터는 복수, 하나밖에 없으면 단수)로 표현한다.
(get post put delete)
: uri에 http method 포함되면 안됨 (get~delete 등이 들어가지 않게 유의)
uri에 동사가 표함되면 안됨

☑️ 예시
[get/user/show/2] =>[get /users/1] : show 같은 것은 필요가 없음

☑️ resource 사이에 연관관계가 있는 경우
[ / resource/고유 id/ 관계있는 리소스] = [get/users/{user_id}/profile
{} : 변수, 파라미터를 통해 받아오는 것을 표현한다.
get users/1/profile : 유저 아이디 1의 프로필정보

☑️ 파일의 경우 Payload의 포맷을 나타내기 위한 파일 확장자를 uri에 포함시키지 않는다.
get /user/1/photo.jpg => get/user/1/photo : jpg 필요없음

☑️ uri / 구분자를 사용해 자원의 계층관계를 나타내는데 사용한다.
/users : 전체 유저 /users/3 : 3번 유저
/users/3/profile-image : 3번유저의 프로필 이미지
☑️ uri의 마지막 문자로 /를 포함하지 않는다.
☑️ 불가피하게 길어지면 - 사용하여 가독성을 높이고, _는 사용하지 않는다.
(아래에 딱 붙어서 잘 안보임)
☑️ uri 경로에는 대문자 사용을 피하도록 규정한다.

3. path parameter, query parameter

* path parameter

get / product : 전체 상품 조회
get/ product/1 : 1번 상품 내용이 딸려옴

Post / products : 상품등록하기
Patch/ products/1 : 상품의 가격을 수정한다.

patch method란? 수정하는 메소드. 일부를 수정한다!
put과의 차이는? put은 전체를 수정한다~

delete products/1 : 1번 상품 삭제
(body에 데이터를 담지 못함. path 파라미터로 주소로 삭제해주면됨)

* query parameter : 필터링시 유용하게 사용이 가능함

get products?price=3000원 : 3000원인 상품
get products?price=3000원&name=사과 :3000원인 상품 중 사과
get products?ordering= - id : id를 기준으로 역순으로 정렬 (- : 역순을 의미! 신상을 정렬할 때 사용하기 좋음)
가격순 등등도 오더링이 가능하다~

-Pagenation
get products?offset=0&limit=100 : 사이트의 상품을 100개씩 정렬해주자.
사이트 페이지에 몇개가 들어갈지 정의해줄 수 있음

-searching
get /users get users?serach=홍길동 : 홍길동을 찾자

* 과연 두가지를 어떨 때 쓰는가?
☑️ path : get product/2
없는 페이지를 부르면? 404 에러가 난다~
불러오는 데이터를 식별해야 할 필요가 있을 때 path 파라미터를 사용한다.

☑️ query get product?id=2
filtering(필터링), sorting(정렬) , searching(검색) 시 사용한다f
없는 페이지를 부르면? 빈 리스트를 반환해준다. 에러는 나지 않는다.
에러가 나면 안되는 상황에 쿼리 파라미터 사용함

4. 잘못된 예시

• 잘못된 예시들
  Get datail_page,
  Get main_page,
  Get find/product(동사들어감),
  Post product_reviews(제품id가 빠짐) ,
  Post product_filter

• 올바르게 고치면?
  product /
  products / (언더바 안으로 세부 카테고리 나열)
  find/product,
  add/product
  post: products/1/reviews,
  products?name =
  

• get이라면 ? 1번 상품의 리뷰를 불러와라
  Post: product_filter =>

• 백엔드는 url 짤 때 기능별, 데이터 기준으로 명시해서 적어주어야 한다!

• 동사, 언더바 등이 들어감.
  이 주소는 백이 프에게 보내는 것, 고객에게 보여주는 것은 프에서 짜는 것이다!

5. status 코드

: 200부터 500까지~
200(get 리소스 반환), 201(생성), 204(삭제 완료),
400(잘못된 요청), 401(로그인필요), 403(특정기능을 못씀), 404(리소스 없을 때) ,405 (post로 만들은 것을 get으로 불러오면?)
500 (서버에러^_^)

users?search=홍길동
쿼리파라미터의 ?는 : 먼저 불러내야할 데이터를 작성하고 ?를 통해 원하는 메소드를 실행
조건끼리 묶을 때는 & 사용

search 사용할 때 : 일부만 검색해도 다 나오게 or 전체 데이터가 일치하게 검색하는 것은
백엔드에서 조건을 어떻게 걸어주느냐에 달렸다!