REST API : 그러니까 창문은 창문답게 투명하게, 보기 쉽게 만들라는 것

주의! 개발공부 한 달 차의 대단히 자의적이며 주관적인 공부 기록입니다.

개념틀과 어휘가 강학상의 혹은 현업상의 그것과 비교하여 크게 다를 수 있습니다. (사실 일단 일부러 자의적으로 구성해나가고 있는 점도 다소 있습니다.)

 

때문에 혹여 이 블로그로부터 정보를 길어가는 일은 몹시 적절하지 못합니다.

방문자에게 이 블로그의 쓸모는 관찰 정도에 있을 것입니다.

'한 달 차는 이런 걸 보고 이런 오해를 하는 구나' 정도 말이지요

---

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

Architectural Styles and the Design of Network-based Software Architectures

 

논문을 지금 읽을 시간은 없고, 원칙 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 헤더를 통해 표현방법 서술.