그때 그시절 기억하고 싶어서 작성했습니다.
약간 일기장 같은 내용이라서 읽는데 있어서 어려움이 있을수 있습니다!
Rest API을 설명하기 앞서서 API란 Representational State Transfer 약자로 상태(State)를 전달(Transfer)하는 것을 나타내는(Representation) 방법이라고 하네요. 여기서 자원의 상태를 주고 받는것이라고 할수 있겠습니다.
Rset는 API를 설계할 URI 자원으로 한정된, 통일되고 일관적인 인터페이스를 구현한다고 합니다. 여기서 URI는 무엇일까요?
구글링 통해서 검색을 해봤습니다. URI는 특정리소스를 식별하는 통합자원 식별자를 의미하고 웹기술에서 사용하는 논리적 리소스를 식별하는 고유한 문자열 시퀀스 입니다.
(여기서 시퀀스는 무엇일까요?? 시퀀스는 일련의 연속적인 사건들 즉, 몇개의 장면이 모여서 하나의 삽화를 이룬것이라고 하네요.)
그리고 헷갈릴수 있는 URL은 웹 주소라고 하며, 컴퓨터 네트워크 상 리소스가 어디 있는지 알려주기 위한 규약입니다.
먼저 URI는 동사를 제외한 명사로 구성하고, Resource에 대한 행위를 HTTP method만으로 표현 합니다. 그리고 Resourse사이에 연관 관계 및 계층 관계가 있는 경우에는 "/"를 사용햐고 응답 Response의 status code의 기본적인 규칙을 따른다고 하네요.
여기서 기본적인 규칙은 HTTP Status code, 상태 코드란 HTTP 요청이 성공했는지 실패했는지를 서버에서 알려주는 코드다.
서버에서는 클라이언트의 요청에 대한 응답으로 상태코드를 보내게 된다.
그리고 상태코드는 서버에서 처리된 결과에 정보를 내포하기에 적절한 상태코드를 사용하여 명시적으로 사용하는게 좋다. 대표적인 status코드는 200번대는 성공응답, 300번대는 리다이렉션으로 리다이렉션은 말 그대로 출력의 방향을 바꾸는것을 말합니다. 즉 사용자 지정위치로 우회할수 있는 다양한 명렁어로 방향지정, 방향변경이라고 할수 있네요. 400번대는 클라이언트 에러, 500번대는 서버에러 입니다.
다시 돌아가서 Rest하게 설계된 API가 발달은 client-server분리와 함께 발달되고 이로 인해 client-server 개별 부분의 발전에 있어서 다른 부분이 영향을 주지 않는 다는 장점이 있다고 합니다.( 다시 말하자면 client-server는 구조를 단순화시키고 작은 단위로 분리함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될수 있도록 한다고 합니다.)
HTTP통신 상태에 대한 정보를 따로 저장하거나 관리 하지 않는것이 (state+less) Rest의 특징입니다. 이러한 특징은 cache를 발달시켰습니다. 그래서 특징요청에 관한 응답을 따로 저장하면서 추후에 재사용이 가능해진다고 합니다.
여기서 stateless는 각 요청 간 클라이언트의 context가 서버에 저장되어서는 안된다고 하네요.
여기서 중요!! 꼭 외워야하는 뜻이라고 합니다.
