개발 일지 - REST API

1. 구현하기

2. 리뷰하기 

2.1 육하원칙 : 학습한 내용. REST Api

언제 사용하면 좋은가	mobile, desktop 등 다양한 어플리케이션에서 HTTP 통신 할때. 완벽히 통제할 수 있다면, 아키텍쳐 스타일을 준수할 필요 없음.
어떤 속성을 갖고 있는가 (Architectural  properties)	성능 - compnent간의 통신의 네트웍 능률과 사용자가 지각한 성능. 확장성 - 많은 수의 component와 component간의 통신을 지원. client-server의 분리로 component의 구현을 단순하게 만들었고, connector semantics의 복잡성을 줄이며, 성능 튜닝에 효과 개선 및 서버 component의 확장성의 증가. Layered system의 중계자 제약 - 프록시, 게이트웨이, 방화벽. 단순성 - 단일 형식의 인터페이스. 변화성 - 변화하는 요구를 충족하기 위한 component의 변화. (어플리케이션이 작동하는 중에도 수정이가능해야함) 가시성 - service agent에 의한 component간의 통신. 이동성 - 데이터로 인해 프로그램 코드가 움직임. 신뢰성 - 데이터, 커넥터, component간의 통신이 시스템 레벨에서 실패하는것.
어떻게 구현하는가 (Architecture Constraints)	Client-server architecture - 독립적인 진화를 위한 분리된 설계.  Client–server model Statelessness - client에서 모든 세션 정보를  갖고 있으며, server는 여기에 대한 반응을 한다. Stateless protocol Cacheability - response를 캐싱하여, 성능 및 확장성을 개선케 한다. Web cache Layered system - 보안성을 띈다 (서버에 직접 연결 되었는지 아닌지) Layered system Code on demand - javaScript와 같은 client-side의 실행 가능한 코드를 갖고 있다. Client-side scripting Uniform interface - Resource indentification in requests - Web-based REST system에서의 URI사용. Resource manipulation through representations - 리소스의 modifiy나 삭제에 대한 정보를 갖고 있는것. Self-descriptive messages - 메세지마다 다음 진행에 대한 정보를 갖고 있는것. Internet media type  Hypermedia as the engine of application state - 접속가능한 URI를 제공할 수 있어야함. (dynamic한 REST service에도 하드코딩 없이 제공해야함.)
왜 사용하는가	client와 server의 독립적인 진화

2.3. 장단점

2.4. 고민한 내용

HTTP api

2.5. 참고 내용
스프링에서 REST 서비스 만들기 (spring io)

그런 REST API로 괜찮은가 (youtube 영상)

데뷰에서 day1에 진행했던 내용입니다.

위키피디아 (한글이 없네여 ㅠㅠ)

2.6. 보충할 점 (구현한 서비스에 대하여)

사용자 구분 없이 서비스를 제공하기 때문에,

여러 사용자가 사용하기엔 무리가 있음.

session을 이용해서 진행하는 방식으로 구분이 필요함.

3. 배경지식

REST는 HTTP를 기반으로 제약 조건과 속성을 정의한 아키텍쳐 스타일 입니다. 
인터넷에서 컴퓨터 시스템간의 통신(상호 운용성)을 제공합니다.
SOAP(Simple Object Access Protocol) 웹 서비스는 정의 되지 않은 임의의 연산을 노출해야 하지만,

REST를 준수한 웹 서비스는 미리 지정된 stateless 연산을 사용하므로 Web resource의 문자적 표현을 변화하거나 접근할 수 있습니다.

Web resources는 URL를 통하여 파일이나 document로  World Wide Web에서 정의하였습니다.

지금은 웹상에서 어떠한 방식으로든 식별가능하고, 이름을 붙이거나, 주소화되거나, 조작가능한 객체와 같이 일반적으로나 추상적으로 정의하는 모든것을 일컫습니다.

RESFful 웹 서비스에서는, XML, HTML, JSON과 같은 방식으로 resource의 URI가 client의 요청에 대한 응답이 될 수 있습니다.

응답은 저장된 resource의 변화가 이루어 졌는지 확인되어야 하며, recourse와 관련된 hypertext 링크를 제공해야 한다.

 HTTP에서는 주로 GET, POST, PUT, DELETE나 CRUD, HTTP methods처럼 이미 정의된 다른 연산을 사용한다.

HTTP methods

Uniform Resource Locator (URL)	GET	PUT	PATCH	POST	DELETE
Collection, such as https://api.example.com/resources/	List  URI에 해당하는 리스트와 컬렉션 맴버의 세부 내용.	Replace 컬렉션 전체를 다른 컬렉션으로 대체.	일반적으로 사용하지 않음.	Create 콜렉션에 새로운 입력을 생성합니다. 새로운 입력의 URI는 자동적으로 배정되며 보통 연산에의하여 반환됩니다.	Delete 콜렉션 전체를 삭제합니다.
Element, such as https://api.example.com/resources/item17	Retrieve  컬렉션의 지정된 맴버를 검색합니다. 물론 인터넷 미디어 타입에 적합하도록 표현.	Replace 커렉션에 지정된 맴버를 대체합니다. 단, 존재하지 않을 경우, 생성.	Update 컬렉션의 지정된 맴버를 업데이트.	일반적으로 사용하지 않습니다. 지정된 맴버를 콜렉션 처럼 취급하고, 새로운 입력을 생성. (idempotent가 아닙니다)	Delete 콜렉션에서 지정된 맴버를 삭제합니다.

stateless protocol과 standard operations를 사용함으로써, REST 시스템는 빠른 성능, 신뢰성, 그리고 진화를 목표로 하고있다.

진화는 관리 가능하고 사이드 이팩트 없는 컴포넌트를 재사용하여 운영중에도 진화가 가능하다.

2000년도에  Roy Fielding의 박사 논문을 통하여 representational state transfer가 소개되었다.

Fielding의 논문에서는 REST의 원칙을 "HTTP object model"로써 설명한 것으로 알려져 있다.

또한, HTTP1.1과 URI의 standard로 설계하는데 사용되었다.

아래와 같은 것이 설계된 웹 어플리케이션의 작동이라고 할 수 있다 :

Web resources(a virtual state-machine)의 네트워크 에서 '/uers/tom '과같은 링크를 클릭했을 때, GET이나 DELETE (state transitions: 상태 전이)가 진행되어

다음 상태의 resource가 결과로 나타나는 것을 나타낼 수 있다.