REST API (이후에 다시 정리)

*API(Application Programming Interface)는 응용 프로그램에서 사용할 수 있도록, 

운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스(어떤 식으로 사용할건지, 통신할건지에 대한 규격, 프로그램 사이의 연결 다리)를 뜻한다.

참고 : https://medium.com/@dydrlaks/api-%EB%9E%80-c0fd6222d34c

REST API의 개념

REST하게 클라이언트랑 서버간에 데이터를 주고 받는 방식

REST 구성(https://meetup.toast.com/posts/92)

• 자원(RESOURCE) - URI
• 행위(Verb) - HTTP METHOD
• 표현(Representations)

REST API : Representational State Transfer 의 약자로 URI는 하나의 고유한 리소스를 대표하도록 설계된다는 개념이다. - 특정 URI (ex: sboard/123 = 123 번째 게시물 ) 처럼 고유한 의미를 가지도록 설계. 

어렵게 생각하지 말자. NON-REST API방식은 화면이 수정될 때마다 화면이 깜빡거린다. 즉, 새로 고침 되는 것이다. 
REST API 방식의 경우 이 깜박거리는 것 없이 고속의 화면전환을 이룬다. - AJAX 를 활용한다.

REST API의 특징

1 . stateless server : 서버가 어플리케이션의 상태를 관리하지 않는다. (쿠키나 세션을 사용하지 않는다.) 

2 . 클라이언트에서 캐시할 수 있도록 캐시가 가능한 응답은 캐시가 할 수 있도록 한다. ( 프록시 활용 ) 

3 . URI 에 너무 많은 정보를 담는 것은 피해야하며 Content type의 정보를 활용해야한다. ex) content-type : Application/json

[ http란 ] 포스트 참조 ( https://abn-abn.tistory.com/185 )

• stateful : server side 에 client와 server의 연속된 동작 상태정보를 저장하는 형태
• stateless : server side 에 client와 server의 연속된 동작 상태정보를 저장하지 않는 형태

http 는 자체적으로 상태정보를 저장 및 유지할 수 없고 application 구현상에서 상태정보를 유지관리해야한다.

따라서 http 그 자체는 stateless 한 프로토콜로 정의할 수 있다. 

결국 sticky session 을 사용해야하는 architecture는 stateful 하다고 이야기 할 수 있다.

이 구현에서 sessionid에 대한 key/value 는 web application framework 상에서 구현된다.

http 의 예에 있어서 각각의 client 요청은 서로 완전히 독립적이고 이전 요청에 의존적이지 않다.

따라서 각각의 요청은 server 가 처리할 수 있도록 하기 위한 모든 정보를 제공해야 한다.

REST architecture 는 stateless 하면서 동시에 어떤 client 관련정보도 서버에 저장하지 않는 방식을 사용한다.

이것이 엄밀한 의미의 stateless 이다. 이런 방식으로 client 가 server 요청시마다 상태정보를 전송하여

서버의 부하를 경감하고 scale-out 을 가능하게 한다. 즉 client 가 상태정보를 모두 관리할 책임을 진다.

참고 : https://shj7242.github.io/2017/10/26/Spring17/

  https://meetup.toast.com/posts/92