-
REST API : 그러니까 창문은 창문답게 투명하게, 보기 쉽게 만들라는 것Tutorial/0.Tutorial 2022. 10. 1. 11:02
주의! 개발공부 한 달 차의 대단히 자의적이며 주관적인 공부 기록입니다.
개념틀과 어휘가 강학상의 혹은 현업상의 그것과 비교하여 크게 다를 수 있습니다. (사실 일단 일부러 자의적으로 구성해나가고 있는 점도 다소 있습니다.)
때문에 혹여 이 블로그로부터 정보를 길어가는 일은 몹시 적절하지 못합니다.
방문자에게 이 블로그의 쓸모는 관찰 정도에 있을 것입니다.
'한 달 차는 이런 걸 보고 이런 오해를 하는 구나' 정도 말이지요
REpresental State Transfer API
Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures" (2000)
챕터 5의 REST 가 눈에 띈다.
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
논문을 지금 읽을 시간은 없고, 원칙 6개.
1. Uniform interface : API 작성을 할 때, 간결하고 형식이 일관되어야 한다. (가장 중요)
-하나의 자료는 하나의 URL (싫은데?)
-URL 예측 가능, 하나 보면 나머지 알 수 있게 (내 맘인데...)
-요청과 응답은 정보가 충분히 들어있어야
-위를 종합하면, URI로 지정한 resource 요청 및 응답을 형식상 일관되게, 그러나 내용상 한정적으로 수행하는 것
-HTTP 프로토콜에 다르는 모든 플랫폼에서 사용가능. 하나의 인터페이스로 느슨한 결합(Loosely Coupling) 형태. (인터페이스의 다형성이 이것과 관련이 있는지?)
2.클라이언트 - 서버 역할구분
-브라우저는 요청만, 서버는 응답만 (다시 하나로 퉁치자)
3.Stateless
-(고객들의) 각각의 요청은 의존성이 없어야 함, 독립적. (의존성 만들면 재밌겠는데?)
4.Cacheable
-서버에서 나오는 정보들이 캐쉬로 잘 들어와야.
5.Layerd System
6.Code on Demand
간단히 정리하면, 매개의 두 산 봉우리 투명성과 반영성 중 투명성을 끌어올리자는 제안.
예시) 알기 쉬운 설계
예시) 예측가능성 : 누가봐도 CRUD 중 read를 하는 페이지이며, 자원은 책에 대한 것, 자료는 Json으로 표현.
router.get('/books', (req, res) => { res.json({ success: true, data: getAllBooks() }); });
REST의 구성요소
1. 자원 Resource - URI
- /movis 처럼 URI에 표시
-/로 계층관계 표시
-밑줄(_) 사용하지 말고 하이픈(-) 사용.
-웬만하면 명사로. 그리고 소문자로만.
-파일확장자 포함하지 않을 것.
2. 행위 - HTTP 프로토콜의 method
-Create : POST
-Read : GET
-Update : PUT, PATCH
-Delete : DELETE
3. 표현
-자원을 어떻게 표현할 것인가 : JSON, XML 등의 형식을 말함.
-HTTP는 Content-Type 헤더를 통해 표현방법 서술.
'Tutorial > 0.Tutorial' 카테고리의 다른 글
웹서버와 웹프레임워크와 라이브러리와 모듈 (0) 2022.10.05 URI 와 URL (0) 2022.10.05 Tutorial 0.4 API (0) 2022.09.05 Tutorial 0.3 Python (0) 2022.08.21 Tutorial 0.0 용어 정리 (0) 2022.08.18