rest api
rest(representational state transfer) 아키텍처 스타일의 설계 원칙을 준수하는 API.
rest란
http uri를 통해 자원을 명시하고 http method(post, get, put, delete, patch 등)를 통해 해당 자원(uri)에 대한 crud operation을 적용하는 것
rest 설계 원칙 6가지
- 균일한 인터페이스
- 클라이언트-서버 분리
- 무상태
- 캐시 가능성:
- 계층화된 시스템 아키텍처
- 코드 온디맨드(선택)
restful api란
엄청 rest한 api
rest api 작성법
| Method | POST, GET, PUT, DELETE, PATCH 등 |
|---|---|
| URI | /products, 개별은 /products/:id |
| Status Code | 성공 201 …/실패 400 … |
| Request Body | {“name”: “상품명”, “price”: 가격}와 같은 형태 |
| Respnose Body | 프론트와 상의, res 다음에 어떤 화면을 띄울지에 따라 다름. |
http란
http의 응답과 요청
request
- start line: http method, request target
- headers: host, content-type, authorization, cookie
- body
response
- status line: status code, message
- headers: content-type, set-cookie
- body
HTTP Method
- post: create
- get: read
- put: update
- patch: update
- delete: delete
+) put과 post가 어떤 용도로 나눠지는지
put과 post의 차이는 멱등성, put 메서드는 멱등성을 가진다. 즉, put은 같은 객체를 여러번 보내도 한 번만 생성되거나 계속해서 같은 값을 보내줄 것이다. post 메서드의 경우 새로운 객체가 보낼 때마다 생성된다.
+) put과 patch가 어떤 용도로 나눠지는지
put 메서드는 요청 페이로드를 사용해 새로운 리소스를 생성하거나 대상 리소스를 나타내는 데이터를 대체한다.
put 메서드는 문서 전체의 완전한 교체만을 허용하지만
patch 메서드는 put 메서드와 달리 부분적인 교체를 할 때 사용하는 메서드.
또한 put은 새로운 자원을 생성하지만 patch는 새로운 자원을 생성하진 않음.
+) put vs patch
- 누가 더 빠를까?
- 누가 더 까다로울까?
- patch가 더 까다롭다
🎀👩🏻💻✨🐾🌷🦅