HTTP 프로토콜 통신 규칙 : 규격화 된 방식으로 통신하자.
REST: 표현 상태 전달
REpresentational State Transfer
REST 스타일을 따르는 API(컴퓨터 기능을 실행시키는 방법, 명령)
REST는 분산 하이퍼미디어 시스템(ex. WEB)을 위한 아키텍쳐 스타일(제약조건들의 집합)
제약조건들을 모두 지켜야 REST를 지킨다고 할 수 있다.
HTTP를 이용해서 기계들이 통신할 때 HTTP를 최대한 활용할 수 있도록 유도하기 위한 모범사례 - 이고잉님
🌠 어떤 URI에 어떤 method를 사용할지 개발자들 사이에 널리 지켜지는 약속
API를 만들 때 규칙에 따라 만들어보자 = RESTful API
특징
REST API를 다르면 각 요청들이 어떤 동작이나 정보를 위한 것인지, 요청만 보고 추론할 수 있다.
서비스를 만들 때 기능만 중요하게 생각한다면 REST를 고려할 필요없이 만든 사람 혼자만 알아볼 수 있더라도 동작만 구현하면 그만이다.
문제는 협업이나 규칙이 없는 API를 활용해야 하는 개발자들은 굉장히 일하기 힘들다.
RESTful 하게 만들어진 API는 요청을 보내는 주소만으로도 대략 어떤 요청을 말하는지 파악할 수 있다.
URI
URI는 URL을 포함 하는 개념.
URI는 인터넷 상의 리소스를 식별하기 위한 문자열의 구성이다.
URL은 리소스의 위치를 나타낸다.
리소스(서버나 DB에 저장된 데이터)를 구조와 함께 나타내는 식별자
리소스 전체를 나타내는 것 : Collection
https://(DOMAIN)/classes - 목록전체를 받아오는 요청
리소스의 한 요소를 나타내는 것 : Element
https://(DOMAIN)/classes/2 - 목록 중에 index에 해당하는 정보
https://(DOMAIN)/classes/rest
리소스를 어떻게 나타내고 표현해야 할까?
API 사용자가 API에 익숙해지고 나면, 다른 요청도 쉽게 만들 수 있어야 한다.
-
리소스를 나타낼 때 동사가 아닌 명사 사용
-
일관성
-
URI는
소문자 -
계층 구조에는
/- URI 끝에
/사용 X
- URI 끝에
-
-사용_는 사용 X
-
파일 확장자 사용 X
-
CRUD는 사용 X
(= C.R.U.D 키워드를 URI에 넣지 말 것)
-
URI는 정보의 식별자일 뿐이고 정보를 가공할 수 있어야 한다.
HTTP Method & C.R.U.D
정보를 가공하기 위한 규칙, method
POST는 쓰고(C) 읽고(R) 수정(U)하고 지울(D) 수 있다. 이 method들의 기능이 한 가지로 제한되어 있지는 않다는 것이다.
하지만 누구든 각 요청의 의도를 쉽게 파악할 수 있도록 RESTful하게 API를 만들기 위해서는 각 method들을 목적에 따라 구분해서 사용해야 한다.
- Create --- POST
- Read --- GET
- Update --- PUT(전체) / PATCH(일부)
- Delete --- DELETE
소포가 편지보다 더 많은 것을 담아 보낼 수 있듯이 POST / PUT / PATCH 에는 body라는 주머니가 있어서 GET / DELETE보다 정보들을 많이, 그리고 비교적 안전하게 감춰서 실어보낼 수 있다.
6가지 CONSTRAINTS
-
Client / Server
클라이언트와 서버는 각각 독립적으로 만들어야 한다. -
Stateless
하나의 요청에 요청에 필요한 정보를 모두 넣어야 한다.
서버는 클라이언트가 누구인지, 어떤 순서인지 알 수 없다. -
Casheable
계속 stateless하게 정보를 보낸다면 매번 정보를 보내야하기 때문에 비효율적
특정 정보를 미리 서버에 저장할 수 있도록 한다. -
Uniform interface
같은 스타일의 API로 만들어서 쉽게 파악할 수 있어야 한다. -
Layered system
접근성. 서버가 어떤 방식으로 되어있고 어떻게 처리되는지 몰라도 API를 사용할 수 있어야 한다. -
Code on demand
JS 코드
RESTful API를 따른 URI
GET Read, data를 읽고 조회
GET http://(DOMAIN)/classes/2/students
➡ 2반의 학생들의 정보를 GET 요청 하고있구나! 를 알 수 있다.
POST Create, 새로운 정보 추가
2반에 새로운 학생이 전학와서 학생정보를 추가한다.
POST http://(DOMAIN)/classes/2/students
➡ 새로운 정보의 idx는 추가되면서 자동으로 부여될 것이기 때문에 요청에 명시할 필요가 없다.
body에 전학 온 학생의 정보를 실어보낸다.
{"idx" : 11, "name" : "전학생", "sex" : "male"},
PUT or PATCH Update, 수정, 기존의 정보를 변경
변경할 학생정보가 있을 때
PUT http://(DOMAIN)/classes/2/students/14
or
PATCH http://(DOMAIN)/classes/2/students/14
➡ 변경할 idx까지 명시해서 수정 할 내용을 body에 실어보낸다.
{"idx" : 14, "name" : "바꿀애", "sex" : "male"},
- PUT은 정보를 통째로 변경할 때
- PATCH는 정보 중 일부를 갈아 끼울 때
filter가 필요할 때: query component를 사용
예를 들어 유튜브API 사용할 때 유튜브 API문서 안내에 따라 해당 쿼리 파라미터들을 적절히 넣어서 원하는 데이터를 뽑아낼 수 있다./managed-devices?region=USA&brand=XYZ&sort=installation-datefiltering이 필요하면 A는 가져오고 B는 가져오지 않겠다는 식으로 query component를 사용한다.
