What if RESTful API!
EndPoint 를 구현하는 방식의 하나
cf) GraphQL API
API에서 전송하는 자원(resource)을 URI로 표현, 해당 자원에 행하고자 하는 의도를 HTTP 메소드로 정의
각 앤드포인트는 리소스를 표현현하는 고유의 URI주소를 가지고 있으며, 해당 리소스에 행할 수 있는 행위를 표현하는 HTTP 메소드를 처리할 수 있게 함
GET
상세페이지와 소통할 때는
특정한 필터를 해서 정보를 가지고 오는 방식을 취해야 한다! (path parameter를 통해서) - 전체를 다 가지고 오는 것은 리소스의 낭비!!
POST - 데이터를 생성해서 집어 넣어주는 것
PATCH - 데이터를 업데이트 해주는 방식
장바구니 수량 업데이트 -
상품의 ID를 Body가 아니라Path Parameter에 담아서 보내줘야 한다
DELETE
잘 지워지면
204 No Content status code 로 리턴 해준다
Querry string(GET parameters)
ex)? - filtering ,
GET /products?price=3000원
GET /products?price=3000원&name=사과
ex) 최신순으로 구현할 때 가능
GET/products?ordering=-id (id의 기준 내림차순으로 반환)
ex) 상품정보 0번째 상품 기준으로 100 개의 상품
GET/ poructs?offset=0&limit=100
ex)
GET /users
GET / users?search=홍길도
PATH parameter vs Query String
같은 리던 값을 받을 수 있는데, 그렇다면 용례는 무엇이낙요?
Query Parameter - >> Filteing / Sorting / Searching / Paginationing
특정한 하나를 가져올때 PATH parameter 사용
결론
RESTful API는
데이터 중심으로!!!! 구성하고 수정해줘야합니다!!
종택님 왈!
View(페이지) 중심이 아니라 자원(데이터)을 중심으로 정리해야 한다 메…모…
offset 좋은예 나쁜예를 잘 생각합니다
카페24가 API 맛집이라는데...?
https://developer.cafe24.com/docs/api/admin/#api-index
각 앤드 포인트는 리소스를 표현하는 고유의 uri 주소를 가지고 있다.
URL - Uniform Resource Locator - 자원 위치 = 서버에 있는 파일 위치를 표시함
URI - Uniform Resource Identifier - 자원 식별자 = 인터넷 세계 속 자원을 나타내는 유일 주소. 프로토콜에 붙어 있음. = URL의 상위 개념. 즉, URI 안에 URL이 있음
Representational
E
State
Transferr
-> Communication
RESTFUL
A
P
I
simply / standardized
scalatle / stateless -
high performacen / cache
