반응형

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)GETPUTPATCHPOSTDELETE
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가 결과로 나타나는 것을 나타낼 수 있다.

반응형

'myProject > React_Lotto_SPA' 카테고리의 다른 글

구현 직후 느낀점  (0) 2018.04.13
반응형

  • 장점
  • 단점
TDD - OOP(객체 지향 프로그래밍)로 요구 사항 변화에 기민성이 높음.
  • TFD(Test First Development)로 코드 안정성 확보.
  • TFD 이후 리팩토링을 통한 클린코드로 가독성 확보.
  • 테스트 가능한 코드로 만들기 때문에, 멀티 쓰레드에서 안정적인 immutable 객체 설계. (JAVA의 장점 : 쓰레드)
  • 데이터 구조가 변경 될 경우, 새로 만드는 작업이 테스트 코드 변경 보다 빠름.

MSA - 단일 객체처럼 작은 단위의 기능만 제공 하는 서비스.

  • 다양한 Apllication에 제공하는 높은 생산성 . ex) Mobile, Desktop 개별 개발을 커버.
  • 기능과 DB 가 1:1구조가 OOP에 적합.
  • 레거시 코드를 MSA에 맞도록 변경하기 어려움.
SPA - 쾌적한 UX제공.
  • 페이지 전체가 아닌 일부분만 변경하여 반응 속도가 빠름.
  • client side의 로직이 필요함. (template엔진으로 대체하기 힘듬)

RESTful Api - 대부분의 기능이 읽기에 집중되어 있음 (80~90%)

  • 컨밴션이 명확하여 개발자간 커뮤니케이션에 좋음.
  • 학습 내용 및 HATEOAS, self-description 등 준수하기 번거로운 면이 있음.

JavaScript Framework - 높은 생산성

  • 기존의 JSP에 비교하여 생산성이 높음.
  • 학습이 제대로 이루어지지 않으면 생산성이 떨어짐.

TDD, MSA, SPA, REST Api, Javascript Framework(이하 React)는 모바일에서 인터넷을 접속하는 현대 시대에 적합한 기술이라고 생각합니다.

그러기에 서로의 필요를 위해 사용하는 기법이라고 생각합니다.


TDD => MSA => REST Api 

  • TDD를 이용하면 MSA에 적합한 코딩이 가능하며, MSA는 REST Api를 통해 사용 범위가 다양해 집니다.


SPA => React => REST Api 

  • SPA는 React를 이용하여 JSP와 같은 템플릿 엔진의 난잡함에서 벗어 날 수 있습니다.
    또한 대부분 사람들이 컴퓨터 보다는 스마트폰을 통하여 인터넷에 접속하는 시간이 더 많기 때문에 시대의 수요에 적합합니다.

REST Api => 다양한 Application의 데이터 통신에 적합합니다.

반응형

'myProject > React_Lotto_SPA' 카테고리의 다른 글

개발 일지 - REST API  (0) 2018.04.14

+ Recent posts

티스토리툴바