요즘 학교에서 여러 과제를 진행하면서 느낀건데,
난 참 아직 모르는게 너무 많구나...하는 생각이 들었다.
그동안 스스로 찾아가며 공부하려고 하지 않았던 업보를 받는건가ㅠㅠ해야할 것들이 너무 많다
그래도 지나간 시간을 후회할 순 없기에 오늘도 열심히 달려본다
그럼 시작!
Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처이다.REST 기반 아키텍처를 사용하여 대규모의 고성능 통신을 안정적으로 지원할 수 있다. 쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있다. API 개발자는 여러 아키텍처를 사용하여 API를 설계할 수 있는데, REST 아키텍처 스타일을 따르는 API를 REST API라고 한다. REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 한다.
요청이 어디에서 오는지와 무관하게, 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 한다. REST API는 사용자의 이름이나 이메일 주소 등의 동일한 데이터 조각이 오직 하나의 URI(Uniform Resource Identifier)에 속함을 보장해야 한다. 이는 클라이언트가 필요로 하는 모든 정보를 포함해야 한다.
REST API 디자인에서 클라이언트와 서버 애플리케이션은 서로 간에 완전히 독립적이어야 한다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI이며, 이는 다른 방법으로 서버 애플리케이션과 상호작용할 수 없어야 한다. 이와 유사하게, 서버 애플리케이션은 HTTP를 통해 요청된 데이터에 전달하는 것 말고는 클라이언트 애플리케이션을 수정하지 않아야 한다.
REST API는 stateless이다. 이는 각 요청에서 이의 처리에 필요한 모든 정보를 포함해야 함을 의미한다. 즉, REST API는 서버측 세션을 필요로 하지 않는다. 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없다.
가능하면 리소스를 클라이언트 또는 서버측에서 캐싱할 수 있어야 한다. 또한 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 한다. 이렇게 하는 이유는 서버측의 확장성 증가와 함께 클라이언트측의 성능 향상을 동시에 얻기 위함이다.
캐싱
주어진 리소스의 복사본을 저장하고 있다가 요청 시에 서버로부터 리소스를 다시 다운받지 않고 해당 복사본을 반환하는 기술
REST API에서는 호출과 응답이 서로 다른 계층을 통과한다. 경험에 따르면 클라이언트와 서버 애플리케이션이 서로 간에 직접 연결된다고 가정하지 않는 것이 좋다. 통신 루프에는 다수의 서로 다른 중개자가 있을 수 있기 때문이다. REST API는 엔드 애플리케이션 또는 중개자와 통신하는지 여부를 클라이언트나 서버가 알 수 없도록 설계되어야 한다.