1. 구현하기

2. 리뷰하기 

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

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처럼 이미 정의된 다른 연산을 사용한다.

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

• 장점

• 단점

• TFD(Test First Development)로 코드 안정성 확보.
• TFD 이후 리팩토링을 통한 클린코드로 가독성 확보.
• 테스트 가능한 코드로 만들기 때문에, 멀티 쓰레드에서 안정적인 immutable 객체 설계. (JAVA의 장점 : 쓰레드)

• 데이터 구조가 변경 될 경우, 새로 만드는 작업이 테스트 코드 변경 보다 빠름.

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

• 다양한 Apllication에 제공하는 높은 생산성 . ex) Mobile, Desktop 개별 개발을 커버.
• 기능과 DB 가 1:1구조가 OOP에 적합.

• 레거시 코드를 MSA에 맞도록 변경하기 어려움.

• 페이지 전체가 아닌 일부분만 변경하여 반응 속도가 빠름.
  

• 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의 데이터 통신에 적합합니다.

요구사항

-    JUnit을 이용하여 진행한다.

-    OOP로 진행을 한다. 소트웍스 앤솔러지

• 규칙 1: 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다.
• 규칙 2: else 예약어를 쓰지 않는다.
• 규칙 3: 모든 원시값과 문자열을 포장한다.
• 규칙 4: 한 줄에 점을 하나만 찍는다.
• 규칙 5: 줄여쓰지 않는다(축약 금지).
• 규칙 6: 모든 엔티티를 작게 유지한다.
• 규칙 7: 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
• 규칙 8: 일급 콜렉션을 쓴다.
• 규칙 9: 게터/세터/프로퍼티를 쓰지 않는다.

출처 : 효과적으로 TDD, 리팩토링, OOP를 연습하는 방법

-    UI없는 화면에서 JAVA 로직으로만 진행.

1차 목표

-    오직 5개의 같은색 돌이 연결되어 있으면 승리.

목표 : 2가지의 알고리즘을 선택한다.

1. 개발자의 오목두는 방식으로 진행.

2. 기존에 널리 알려진 오목, 바둑 에 사용되는 알고리즘 중에 채택하여 사용.

방식 1에 대한 알고리즘

1. Tree를 선택하여 가중치를 준다.
    Tree의 width( 선택 가능한 방향의 개수)
    Tree의 depth( 비어 있거나 같은 색의 돌의 개수)

소스 - https://github.com/derren-korean/gomoku1

전체적인 맥락

3차에 걸쳐 프로젝트를 진행한다.

1차.

승리 조건 : 

1. 나란히 있는 돌의 색을 판단.

2. 1을 만족하고, 그 방향이 가로, 세로, 대각선으로 일정한 방향인지 판단.

3. 2를 만족하고, 그 갯수가 5개인지 판단.

모델링 : 

돌, 보드, 플레이어, 주심

테스트 코드 : 

1. 색 판단

2. 돌 방향

3. 5개 나란히 있을 경우 승리조건이 만족하는지

4. 각 방향 별로 3번이 만족하는지

코딩 :

소켓 통신으로 플레이어 1,2를 모두 테스팅

테스트 코드 :

Program 착수 로직

2차

승리 조건 :

각 오목 규칙과 각 게임 방법에 따른 조건 만족 시.

3차

불계승, 타이머, 

모델링

1. 돌순번 : 1base로 하며, 최대 19 x 19까지 가능한 수를 갖는다.

2. 돌 : 색깔과 순번을 갖는다.

4. 오목판 : 좌표를 갖는다.

6. 플레이어 : 돌의 착점을 선택한다.

7. 기보 : 돌의 순서를 좌표별로 저장한다.

8. 규칙 : 게임의 규칙을 설정한다.

9. 타이머 : 착수의 시간을 제한한다.

10. 경기방법 : 3가지 경기 방법을 갖는다.

11. 규칙확인 : 착점시 규칙 위반 여부를 판단한다. 

12. 승자판단 : 오목이 완성되어있는지 확인.