업그레이드 하는 이유는 다음과 같습니다

Unsupported major.minor version 52.0 이 오류때문인데요

이유가 개발할때 자바버젼이 J2SE 8에서 했는데 실행할때 자바버젼이 J2SE 8보다 낮으면 발생하는 문제였습니다

제가 설치할 때 J2SE 7로 설치를 해서 이번 기회를 통해서 J2SE 8로 업그레이드 해주기로 결정했습니다

저는 기본에 RPM으로 openJDK를 설치해 놓았기 때문에 기존 7버젼을 지우고 8버젼을 새로 설치하기로 했습니다

1)설치된 자바 버젼 확인

rpm -qa | grep jdk

2)설치된 7 버젼 지우기

yum remove java-1.7.0-openjdk-1.7.0.171-2.6.13.0.el7_4.x86_64

정상적으로 지우졌습니다

3)자바 설치가능 리스트 확인

yum list java*jdk-devel

4)자바 8 버젼 설치

yum install java-1.8.0-openjdk-devel.x86_64

설치 완료 되었습니다

5) 자바 8 버젼 설치 확인

rpm -qa java*jdk-devel

6) 자바 버젼 확인

java -version

업그레이드 되었네요^^

Do it 코틀린 프로그래밍 책에서 참고

자바가 있는데 왜 코틀린을 배워야 하나요?

코틀린은 자바에 없던 널검사, 코루틴, 고차함수나 람다식과 같은 기능을 제공합니다

이 기능들은 대부분 안전하고 효율적인 프로그래밍을 위해 만들어졌으며 대부분의 현대 언어가 가지고 있는 특징이므로 프로그래밍 실력 향상을 위해 꼭 공부하기를 권장합니다

자바로 작성한 안드로이드 애플리케이션을 코틀린으로 쉽게 바꿀 수 있나요?

코틀린은 자바와 완벽하게 호환됩니다. 그래서 코틀린으로 작성한 프로그램에 자바의 방대한 라이브러리를 그대로 추가할 수도 있습니다. 심지어 안드로이드 스튜디오에서는 자바를 코틀린으로 변환하는 기능도 제공합니다

코틀린을 상용 안드로이드 애플리케이션에 바로 도입해도 될까요?

코틀린은 에버노트, 트렐로, 코세라 등과 같은 여러 유명 기업의 안드로이드 애플리케이션에 적용되고 있습니다. 그만큼 안정성이 입증된 언어입니다. 또 구글이 코틀린을 안드로이드 공식 언어로 채택했으므로 앞으로 코틀린은 안드로이드 애플리케이션 개발 필수 언어가 될 것 입니다

코틀린은 인텔리제이 IDEA라는 통합개발환경으로 유명한 JetBrains에서 개발

구글의 안드로이드 스튜디오도 인텔리제이 IDEA기반이며 코틀린 언어를 공식으로 지원

코틀린의 용도(멀티 플랫폼 언어)

-Kotlin/JVM : 자바 가상 머신에서 동작하는 애플리케이션을 만들 수 있다

-Kotlin/JS : 자바스크립트로 웹 브라우저에서 동작하는 애플리케이션을 만들 수 있다

-Kotlin/Native : LLVM 컴파일러를 이용하여 여러 플랫폼을 타깃으로 하는 애플리케이션을 만들 수 있다

코틀린의 장점

1)자료형 오류를 미리 잡을 수 있는 정적 언어

코틀린은 프로그램이 컴파일될때 자료형을 검사하여 확정하는 정적 언어입니다. 즉 자료형 오류를 초기에 발견할 수 있어 프로그램의 안정성이 좋아집니다

2)널 포인터 예외로 인한 프로그램의 중단을 예방할 수 있습니다

널 포인터 예외(NullPointerException)는 프로그램이 실행되는 도중에 발생하기 때문에 언제 어디서 어떻게 발생할지 아무도 알 수 없습니다. 오랫동안 프로그래머의 골치를 아프게 만들었지만 코틀린에서는 예방할 수 있습니다

3)아주 간결하고 효율적입니다

코틀린은 여러가지 생략된 표현이 가능한 언어입니다. 그래서 다른 언어보다 훨씬 간결하고 효율적으로 코딩할 수 있습니다.

4)함수형 프로그래밍과 객체 지향 프로그래밍이 모두 가능합니다.

함수를 변수에 저장하거나 함수를 다른 함수의 매개변수로 넘길 수 있는 함수형 프로그래밍과 클래스를 사용하는 객체 지향 프로그래밍을 둘다 할 수 있습니다

5)세미콜론을 생략할 수 있습니다

코드를 작성할때 줄 마지막에 사용하던 세미콜론을 생략할수도 있습니다

코틀린 리액티브 프로그래밍 책(2019)에서 참고

리액티브 프로그래밍은 데이터 스트림과 변경 사항 전파를 중심으로 하는 비동기 프로그래밍 패러다임

간단히 말하면, 데이터와 데이터 스트림에 영향을 미치는 모든 변경사항을 관련된 모든 당사자들, 예를 들면 최종 사용자나 컴포넌트, 하위 구성요소, 또는 어떻게든 연결돼 있는 다른 프로그램 등에게 전파하는 프로그램을 리액티브 프로그램이라고 한다

예를 들어 엑셀에서 한셀에 식이 있고 다른셀에는 식에서 쓰는 값이 있을때 값을 바꾸면 식의 결과도 자동으로 바뀌는데 이것을 리액티브라고 한다

함수형 리액티브 프로그래밍을 적용해야 하는 이유

1)콜백 지옥의 제거

콜백은 미리 정의된 이벤트가 발생할 때 호출되는 메서드다. 인터페이스를 콜백메서드와 함께 전달하는 매커니즘을 콜백 매커니즘이라고 부른다.

2)오류 처리를 위한 표준 매커니즘

3)간결해진 스레드 사용

스레드를 코틀린에서 자바에 비해 더 쉽게 사용할 수 있지만, 여전히 복잡하다. 리액티브 프로그래밍을 통하면 한층 더 쉽게 사용할 수 있다

4)간단한 비동기 연산

스레드와 비동기 작업은 서로 연관돼 있다. 스레드 사용이 쉬워질수록 비동기 연산도 쉬워진다.

5)전체를 위한 하나, 모든 작업에 대해 동일한 API

리액티브 프로그래밍, 특히 RxKotlin은 간단하고 직관적인 API를 제공하는데 네트워크 호출, 데이터베이스 접근, 계산 또는 UI 연산 등 어느 곳에서나 어떤 것을 대상으로든 사용할 수 있다

6)함수형 접근

리액티브 프로그래밍을 사용하면 함수형 접근 방법을 취해서 가독성이 좋은 선언적 코드를 작성할 수 있다

7)유지 보수 가능하고 테스트 가능한 코드

가장 중요한 점으로 리액티브 프로그래밍을 올바르게 수행하면 프로그램의 유지보수와 테스트가 한층 더 쉬워진다

리액티브 선언(http://www.reactivemanifesto.org)은 네가지 리액티브 원리를 정의해 놓은 문서

리액티브 선언의 4원칙

1)응답성(Responsive)

시스템은 증각 응답해야 한다. 응답성 있는 시스템은 신속하고 일관성 있는 응답시간을 유지해 일관된 서비스 푸짐을 제공한다

2)탄력성(Resilent)

시스템에 장애가 발생하더라도 응답성을 유지해야 한다. 탄력성은 복제(replication), 봉쇄(containement), 격리(isolation), 위임(delegation)에 의해서 이루어진다. 장애는 각 컴포넌트 내부로 억제돼 각 컴포넌트들을 서로 격리시키는데, 그래서 하나의 컴포넌트에 장애가 발생하더라도 전체 시스템에 영향을 끼치지 못하게 된다

3)유연성(Elastic)

리액티브 시스템은 작업량이 변하더라도 그 변화에 대응하고 응답성을 유지해야 한다

리액티브 시스템은 상용 하드웨어 및 소프트웨어 플랫폼에서 효율적인 비용으로 유연성을 확보한다

4)메시지 기반(Message Driven)

탄력성의 원칙을 지키려면 리액티브 시스템은 비동기적인 메시지 전달에 의존해 컴포넌트들 간의 경계를 형성해야 한다

리액티브 스트림 표준 사양

http://www.reactive-streams.org 

코틀린을 위한 리액티브 프레임워크

리액티브 프로그램을 작성하려면 라이브러리 또는 특정 프로그래밍 언어가 필요하다. 코틀린은 자바, 안드로이드와 완벽하게 상호 운용되며 멀티 플랫폼 애플리케이션을 위한 강력하고 유연한 프로그래밍 언어이기 때문에 코틀린을 리액티브 언어라고 볼 수는 없다(애초에 리액티브 언어라고 하는 프로그래밍 언어를 들어본 적이 없다)

그러나 도움이 되는 라이브러리가 있다

-RxKotlin

-Reactor-Kotilin

-Redux-Kotlin

-FunKTionale

-RxJava와 그외의 자바 리액티브 프레임워크도 코틀린과 함께 사용할 수도 있다(코틀린은 자바와 100% 상호 운용 가능하기 때문)

REST API

1. 자원(resource) : URI

2. 행위(verb) : HTTP 메서드

3. 표현(representations) : 리소스에 대한 표현(HTTP Message Body)

1. URI 설계

URI는 URL을 포함하는 개념입니다

URL이 리소스를 가져오는 방법에 대한 위치라면 URI는 문자열을 식별하기 위한 표준입니다

URI는 명사를 사용해야 하며 동사를 피해야 합니다.

모든 경우에 완벽하게 호환되지는 않습니다. 세부적인 동사의 경우 URI에 포함될 수 밖에 없습니다.

가령 모바일 결제라는 REST API를 설계한다고 가정할 경우 OTP발행, 결제 진행, 기타 API 동작에 대해 HTTP메서드만으로는 대응하기 힘듭니다. 앞의 URI 설계에 대한 원칙은 어디까지나 불필요한 동사를 URI에 포함하는 것을 지양해야 한다는 것이지 완전히 배제시킨다는 것은 아닙니다

URI에서는 명사에 단수형보다는 복수형을 사용해야 합니다

컬렉션으로 URI를 사용할 경우 컬렉션을 한번 더 감싼 충첨 형식으로 사용하는 것이 종습니다

_embedded:[

   {

    books:....

   },

   {

    stores:....

   },

   {....}

]

2. 행위 설계

/books의 경우 book의 목록을 표현한다는 기본 전제가 깔려 있습니다.

/books 자체가 복수의 book을 의미하므로 books를 게시판에 표현할 때 페이징을 처리하는 값을 추가로 제공할 수도 있습니다.

ex) /books?page=0&size=10&sort=desc

page, size, sort 파라미터를 따로 지정하지 않으면 서버에서 기본으로 설정한 값으로 반환됩니다

처음 배우는 스프링 부트2에서 참고

메이븐은 pom.xml로 XML기반으로 작성되어 있어서 동적인 행위에 제약이 있어서 대안으로 나온 그루비 기반의 Gradle이 주목받고 있습니다

Gradle은 Ant로부터 기본적인 빌드 도구의 기능을, 메이븐으로부터 의존 라이브러리 관리 기능을 차용했습니다.

멀티 프로젝트 구성 시에는 메이븐처럼 상속 구조가 아닌 설정 주입 방식을 사용하여 훨씬 유연하게 빌드 환경을 구성할 수 있습니다.

https://gradle.org/install/

https://gradle.org/guides/#getting-started

Gradle 설정 관련 기본 구조

1. gradlew : 리눅스 및 맥OS 용 쉘 스크립트

2. gradlew.bat : 원도우용 배치 스크립트

3. gradle/wrapper/gradle-wrapper.jar : Wrapper JAR

4. gradle/wrapper/gradle-wrapper.properties : Gradle 설정 정보 프로퍼티 파일(버전 정보 등)

처음 배우는 스프링부트 2 책에서 참고

스프링 부트 특징

1. 임베디드 톰캣(Embed Tomcat), 제티, 언더토우를 사용하여 독립 실행이 가능한 스프링 어플리케이션 개발

2. 통합 스타터를 제공하여 메이븐/그래들 구성 간소화

3. 스타터를 통한 자동화된 스프링 설정 제공

4. 번거로운 XML설정을 요구하지 않음

5. JAR을 사용하여 자바 옵션만으로도 배포 가능

6. 애플리케이션의 모니터링과 관리를 위한 스프링 액츄에이터(Spring Actuator) 제공

스프링 부트 장점

1. 각각의 의존성 버전을 올리는 것이 좀 더 수월합니다.

스프링 부트의 버전이 올라갈때마다 각 버전 간의 호환성에 대해 충분한 테스트를 거치고 릴리스되기 때문에 기존에 하나씩 수동으로 설정했던 버전 관리에 비해 안정된 버전이 제공된다는 최소한의 보장을 얻을 수 있습니다.

2. 특정 라이브러리에 버그가 있다 하더라도 스프링팀에서 버그픽스한 버전을 받기 편리합니다

3. 간단한 어노테이션 설정이나 프로퍼티 설정으로 세부적인 설정 없이 원하는 기능을 빠르게 적용할수 있습니다.

4. 별도의 외장 톰캣을 설치할 필요가 없으며 위와 동일한 이유로 톰캣 버전도 더욱 편리하게 관리합니다.

스프링 부트 단점

1. 설정을 개인화(커스터마이징)하면 버전을 올릴 때 기존 스프링 프레임워크를 사용하는 것과 동일한 불편함을 겪을 수 있습니다.

2. 특정 설정을 개인화 혹은 설정 자체를 변경하고 싶다면 내부의 설정 코드를 살펴봐야 하는 불편함이 있을 수 있습니다.

spring boot starters 목록

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using-boot-starter

스프링에서 사용가능한 템플릿 엔진 종류들

https://www.baeldung.com/spring-template-engines

위의 스프링에서 사용가능한 템플릿 엔진 성능순위(비교)

https://github.com/jreijn/spring-comparing-template-engines

결과는 다음과 같습니다~ㅎ

Freemarker나 Mustache 나 Thymeleaf 쓰는 것이 좋아보이네요~ㅎ

스프링 부트로 배우는 자바 웹 개발 책과 처음 배우는 스프링 부트2 책에서 참고

REST는

-Representational State Transfer의 약자

-분산 네트워크 프로그래밍의 아키텍쳐 스타일

-웹과 같은 분산 하이퍼미디어 시스템에서 사용하는 통신 네트워크 아키텍처로, 네트워크 아키텍처의 원리 모음입니다

웹은 전송 방식으로 HTTP를, 식별방법으로 URI를 사용합니다

HTTP는 웹에서 GET, POST, PUT, DELETE 등의 메서드를 사용하여 정보를 주고받는 프로토톨입니다

REST는 HTTP와 URI의 단순하고 간결한 장점을 계승한 네트워크 아키텍처입니다

따라서 다양한 요구사항에 대응하여 때로는 단순하게, 때로는 서버와 클라이언트가 서로 통신하는 리소스에 대해 복잡한 방식으로 상호작용할 수 있습니다

REST의 목적

1. 구성요소 상호작용의 규모 확장성

2. 인터페이스의 범용성

3. 구성요소의 독립적인 배포

4. 중간적 구성요소를 이용한 응답 지연 감소, 보안 강화, 레거시 시스템 인캠슐레이션

RESTful의 제약 조건

REST의 구현 원칙을 제대로 지키면서 REST 아키텍처를 만드는 것을 RESTful이라고 함

1. 클라이언트/서버

: 클라이언트와 서버가 서로 독립적으로 구분되어야 하고 서버 또는 클라이언트 증설 시에 서로간의 의존성 때문에 확장에 문제가 되는 일이 없어야 한다

2. 상태 없음

:클라이언트와 서버 간의 통신시에 상태가 없어야 한다. 단순히 들어오는 요청만 처리하여 구현을 더 단순화한다. 단 클라이언트의 모든 요청은 서버가 알아듣는 데 필요한 모든 정보를 담고 있어야 한다.

3. 레이어드 아키텍쳐(Layered Architecture)

:서버와 클라이언트 사이에 중개서버(게이트웨이, 방화벽, 프록시)나 로드밸런싱, 공유캐시가 있는 것처럼 다계층 형태로 레이어를 추가하거나 수정하거나 제거할 수 있고 확장성이 있어야 한다

4. 캐시가능(cacheable)

:서버의 응답들은 캐시를 가지고 있거나 없거나 둘 중의 하나인데, 캐시를 가지고 있을 경우에는 클라이언트가 캐시를 통해서 응답을 재사용할 수 있고 이를 통해서 서버의 부하를 낮추어서 서버의 성능이 향상될 수 있다. HTTP장점을 그대로 계승한 아키텍쳐가 REST라서 HTTP의 캐시 기능을 적용할 수도 있습니다

5. 코드 온 디멘드(Code On Demand)

:요청이 오면 코드를 준다는 의미로 특정 시점에 서버가 특정 기능을 수행하는 스크립트 또는 플러그인을 클라이언트에 전달해서 해당 기능을 동작하도록 하는 것이다. 코드 온 디멘드의 예로는 애플릿, 자바스크립트, 플래시가 있다. 이 제약조건은 선택가능합니다.

6. 통합 인터페이스

서버와 클라이언트 간의 상호 작용은 일관된 인터페이스들 위에서 이뤄져야 한다

통합 인터페이스 규칙

1. 리소스 식별

:웹 안에서 서로 구분할 수 있는 개념으로 URI와 같은 고유 식별자를 통해 표현할 수 있다

2. 표현을 통한 리소스 처리

:사람의 말에 강세가 있어서 같은 문장을 말하더라도 말한 사람의 강세나 어조에 따라 의도가 달라질 수 있듯이 같은 데이터에 대해서 표현할 때 JSON, XML, HTML 페이지와 같이 다양한 콘텐츠 유형으로 표현할 수 있다. 그렇지만 말의 강세나 어조가 바뀌어도 문장 자체는 그대로인 것처럼 데이터는 변경되지 않는다.

3. 자기 묘사 메시지

:일반적으로 네트워크 통신을 할 때는 헤더부분에 현재 보내고 있는 데이터 패킷에 대한 메타 정보를 담아서 본문을 읽을 때 해당 본문이 어떤 의도로 쓰여진 것인지 알 수 있다. 마찬가지로 HTTP 통신을 할때도 HTTP header에 메타 데이터 정보를 추가해서 실제 데이터와는 관련 없지만 데이터에 대한 설명을 나타내는 정보를 담을 수 있다

4. 애플리케이션의 상태에 대한 하이퍼미디어(HETEOAS, Hypermedia As The Engine Of Application State)

간단히 말해서 웹은 여러 페이지들과 그 페이지들을 이동할 수 있는 링크 정보들로 구성되어 있다. REST API를 개발할때도 단순히 데이터만 전달하지 않고 링크 정보까지 포함한다면 좀 더 웹에 친숙한 API가 될 것이다

적어놓고도 어려워서 다른 블로그 글을 아래에 첨부하였음

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

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