이전 버전 oracle jdk를 제거하고 최신 버전으로 설치하는 법

💻 OS: Window10

저번에 이전 버전 jdk를 제거하지 않고 최신 버전으로 설치하였다가 꽤나 문제가 생겼기 때문에

이번에 java8에서 java11로 버전 업그레이드하기 전에 삭제하는 법에 대해서 찾아보았습니다.

나중에도 찾지 않고 빠르게 삭제하고 싶어 글을 작성합니다.

1. [제어판]-[프로그램 및 기능]

2. [프로그램 제거 또는 변경]에 들어가서 Java로 시작하는 파일들을 삭제해줍니다.

저 캡처본을 보면 3개의 프로그램을 제거해주시면 됩니다. (보통 2개 깔려있음, Development Kit, Update)

3. www.java.com/ko/download/uninstalltool.jsp 접속해서 "약관에 동의하고 계속합니다." 버튼을 클릭하면

실행파일이 나오고 실행파일을 실행시켜주면 됩니다.

4. 저는 이미 제어판으로 삭제했기 때문에 No Java Versions Detected 문구가 뜨고,

저 페이지를 먼저 접속하셨으면 자동적으로 Java jdk이 삭제됩니다.

5. 다시 설치하실 때는 환경변수 설정을 꼭 변경해주는 것도 잊지 말 것

RESTful API - 첫 번째 이야기

4. REST API 디자인 가이드

REST API 설계시 가장 중요한 항목은 2가지로 요약할 수 있다.

1. URI는 정보의 자원을 표현해야 한다.

2. 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE)로 표현한다.

4-1. REST API 중심 규칙

1. URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)

GET /members/delete/1

위와 같은 방식은 RESTS를 제대로 적용하지 않은 URI

URI는 자원을 표현하는데 중점을 두어야 한다. delete와 같은 행위에 대한 표현이 들어가면 안된다.

2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현

위의 잘못된 URI를 HTTP Method를 통해 수정하면

DELETE /members/1

으로 수정할 수 있다.

회원 정보를 가져올 때는 GET, 회원을 추가할 때는 POST Method를 사용하여 표현한다.

회원 정보를 가져오는 URI

GET /members/show/1 (x)
GET /members/1        (o)

회원을 추가하는 URI

GET /members/insert/2 (x) - GET 메서드는 리소스 생성에 맞지 않는다.
POST /members/2       (o)

HTTP Method의 알맞은 역할

(RESTful API 첫번째 이야기 1-2 에 쓰여있고, 뒤에서도 설명)

POST : 해당 URI를 요청하면 리소스를 생성한다.

GET :  해당 리소스를 조회한다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.

PUT : 해당 리소스를 수정한다.

DELETE : 리소스를 삭제한다.

4-2. URI 설계 시 주의할 점

1) 슬래시 구분자 (/)는 계층 관계를 나타내는 데 사용

http://restapi.example.com/houses/apartments
http://restapi.example.com/animals/mammals/whales

2) URI 마지막 문자로 슬래시(/)를 포함하지 않는다.

URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다. REST API는 분명한 URI를 만들어 통신을 해야하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.

http://restapi.example.com/houses/apartments/ (X)
http://restapi.example.com/houses/apartments (0)

3) 하이픈(-)은 URI 가독성을 높이는 데 사용

URI를 쉽게 읽고 해석하기 위해, 불가피하게 긴 URI 경로를 사용해야 할 경우 하이픈을 사용해 가독성을 높인다.

4) 밑줄(_)은 URI에 사용하지 않는다.

가독성 문제로 밑줄 대신 하이픈을 사용하는 것이 좋다.

5) URI 경로에는 소문자가 적합하다.

URI 경로에 대문자 사용은 피해야 한다. 대소문자에 따라 다른 리소스로 인식하게 되기 때문이다. RFC 3986(URI 문법형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이다.

6) 파일 확장자는 URI에 포함시키지 않는다.

http://restapi.example.com/members/soccer/345/photo.jpg (X)

REST API 에서는 메시지 바디 내용의 포맥을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다. Accept header를 사용한다.

4-3. 리소스 간의 관계를 표현하는 방법

REST 리소스 간에 연관 관계가 있을 수 있는데 이런 경우 다음과 같은 표현 방법을 사용한다.

/리소스/리소스 ID/관계가 있는 다른 리소스명

예) GET: /users/{userid}/devices (일반적으로 소유 'has'의 관계를 표현할 때)

만약에 관계명이 복잡하다면('has'의 관계가 아닐 때) 이를 서브 리소스에 명시적으로 표현하는 방법이 있다. 예를 들면 사용자가 '좋아하는(like)' 디바이스 목록을 표현해야 할 경우

GET : /users/{userid}/likes/devices (관계명이 애매하거나 구체적 표현이 필요할 때)

4-4. 자원을 표현하는 Collection과 Document

Collection과 Document에 대해 알면 URI 설계가 한 층 더 쉬워진다. Document는 단순히 문서 또는 한 객체, Collection은 문서들의 집합, 객체들의 집합으로 생각한다. 컬렉션과 도큐먼트는 모두 리소스라고 표현할 수 있으며 URI에 표현된다.

http:// restapi.example.com/sports/soccer

위 URI에서 sports라는 컬렉션과 soccer이라는 도큐먼트로 표현되어 있다고 생각하면 된다.

http:// restapi.example.com/sports/soccer/players/13

sports, players 컬렉션과 soccer, 13(13번인 선수)를 의미하는 도큐먼트로 URI가 이루어지게 된다. 여기서 중요한 점은 컬렉션은 복수로 사용하고 있다는 점이다. 좀 더 직관적인 REST API를 위해서 컬렉션과 도큐먼트를 사용할 때 단수/복수를 지켜준다면 이해하기 쉬운 URI를 설계할 수 있다.

RESTful Web Service HTTP methods

Collection URI (예) http:// example.com/resourses

GET : 컬렉션에 속한 자원들의 URI나 그 상세사항의 목록을 보여준다.

PUT : 전체 컬렉션은 다른 컬렉션으로 교체한다. 

POST : 해당 컬렉션에 속하는 새로운 자원을 생성한다. 자원의 URI는 시스템에 의해 할당된다.

DELETE : 전체 컬렉션을 삭제한다.

Element(Document) URI (예) http:// example.com/resoureces/item17

GET : 요청한 컬렉션 내 자원을 반환한다.

PUT : 해당 자원을 수정한다. 

POST : 해당 자원에 귀속되는 새로운 자원을 생성한다.

DELETE : 해당 컬렉션 내 자원을 삭제한다.

5. HTTP 응답상태 코드

잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 한다. 정확한 응답의 상태코드만으로도 많은 정보를 전달할 수가 있기 때문에 응답의 상태코드 값을 명확히 돌려주는 것은 생각보다 중요한 일이다. 

[참고]

https://spoqa.github.io/2012/02/27/rest-introduction.html

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

Wrapper Class 

1. 기본 자료형 클래스

byte, short, int long, float, double, boolean, char

기본 자료형을 객체로 변환하기 위해서, 기본 자료형 각각에 대한 클래스가 Java 표준 라이브러리(java.lang 패키지)에 포함되어 있다.

• byte - Byte
• short - Short
• int - Integer
• long - Long
• float - Float
• double - Double
• boolean - Boolean
• char - Character

기본 자료형 클래스에는 equals 메소드가 재정의되어있음.

Integer x = new Integer(3); 
Integer y = new Integer(3); 
System.out.println(x.equals(y)); // true 출력!!!!

2. Auto-boxing & Auto-unboxing

래퍼 클래스는 산술 연산을 위해 정의된 클래스가 아니므로, 인스턴스에 저장된 값을 변경할 수 없다.

단지, 값을 참조하기 위해 새로운 인스턴스를 생성하고, 생성된 인스턴스의 값만을 참조할 수 있다.

Auto-boxing

Object a1 = 3;
Object a2 = new Integer(3);

둘은 같은 코드
컴파일러가 윗 코드를 아래코드로 자동으로 생성 Autoboxing

Auto-unboxing

Integer i1 = new Integer(3); 
int i2 = i1;
int i2 = i1.intValue();

3. nullable integer

null 값이 가능한 int값을 java 변수에 대입하려면 기본 자료형이 int 변수를 사용할 수 없고 Integer 객체 참조 변수를 사용해야한다.

1. REST 란?

REpresentation State Transfer (자원을 이름으로 구분해 해당 자원의 상태를 주고받는 것)

REST는 웹에 존재하는 자원(이미지, 동영상, 데이터)에 대해서 고유한 URI를 부여하고 활용하는 방법론을 의미한다.

하나의 URI는 하나의 고유한 Resource를 대표하도록 설계된다는 개념

웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍처 (웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용 가능)

www(World Wide Web)과 같은 분산 시스템을 위한 소프트웨어 아키텍쳐

1-1. REST의 3요소

* Resource (자원) URI는 정보의 자원을 표현해야 한다.

* Method (행위) HTTP Method

* Representation of Resource (표현)

HTTP 의도에 맞게 활용된다는 것은,

1. URI는 정보의 자원을 표현해야 한다.

2. 자원에 대한 행위는 HTTP Method(GET 생성, POST 조회, PUT 수정, DELETE 삭제)로 표현하는 것을 말한다. 즉, URI로 주어나 목적어를 만들고 HTTP Method로 동사를 만든다는 개념.

URI를 불분명한 자원으로 표현하거나 혹은 동사처럼 사용하거나, HTTP Method 중 GET을 쓰면서 수정도 하고 삭제도 하는 것은 RESTful하지 않다.

1-2. HTTP와 REST

REST는 결국 URI를 이용해서 제어할 자원을 명시하고, HTTP를 이용해서 제어 명령을 내린다.

HTTP에 여러 Method가 있지만 REST에서는 CRUD에 해당하는 4가지 Method만 사용한다.

* C reate = POST

* R ead = GET

* U pdate = UPDATE

* D elete = DELETE

Resource를 URI로 정해준 뒤에 HTTP Method를 이용해서 CRUD를 구현하고 Message를 JSON(혹은 XML)로 표현하여 HTTP Body에 실어 보내면 된다.

2. REST의 설계 목표

* 컴포넌트들 간의 상호연동성 확보

 - 리눅스의 파이프가 상이한 프로세스들을 연동하는 것처럼, REST API는 복수의 컴포넌트들을 결합함으로써 작업을 더 효율적으로 수행하게 한다.

* 범용 인터페이스 제공

 - REST 모델을 위한 HTTP와 URI는 표준이므로 어디서든 사용 가능한 범용 인터페이스를 제공한다. 개발자는 비즈니스 로직만 고민하면 된다.

* 각 컴포넌트들의 독립적인 배포

* 지연감소, 보안 강화, 레거시 시스템을 인캡슐레이션 하는 중간 컴포넌트로의 역할

REST의 목표를 가지고 작업을 수행할 시, 백엔드와 프런트엔드의 영역을 효율적으로 분리할 수 있어 규모 확장에 있어 장점이 생기고 독립적으로 배포되어 버전 관리를 할 수 있다. 

자원과 직접적인 통신을 하고 있는 백엔드가 분리되어 있기 때문에 접근하는 것에 있어서나 자원을 캡슐화해서 보낼 수 있어 보안이 강화된다는 장점이 있다.

3. REST의 6가지 특성/제약

1. Stateless (무상태성)

* 상태가 없다는 것은 사용자나 클라이언트의 Context를 서버 쪽에 유지하지 않는다는 의미

* HTTP Session과 같은 Context 저장소에 상태 정보를 저장하지 않는다는 것이다.

* 상태 정보를 저장하지 않으면 각 API 서버는 들어오는 메시지로만 처리하면 되고, Session과 같은 Context 정보를 신경 쓸 필요가 없다. -> 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않아 구현이 단순해진다.

2. Client - Server (클라이언트 - 서버 구조)

* 클라이언트와 서버가 서로 분리되어야 한다.

* 예를 들어, 개발자가 모바일 어플의 Client 단을 수정할 때 Server 단의 데이터 베이스 디자인에 영향을 끼치지 않고 수정할 수 있어야 한다. (거꾸로도 마찬가지)

* 역할이 구분되면 개발자 관점에서 클라이언트와 서버에서 개발해야 할 내용들이 명확해지고 의존성이 줄어든다.

3. Layered System (계층형 구조)

* MVD 모델에서 Model, View, Controller 가 각각 역할을 담당하고 서로 상호작용하듯이, REST API에서도 아키텍처의 서로 다른 계층이 협업을 하여 확장성과 유연성을 증가시킨다.

* 클라이언트 입장에서는 대상 서버에 직접 연결되었는지, 중간 서버를 통해 연결되었는지 알 수 없다. 즉, REST API 서버만 호출한다. 그러나 서버는 다중 계층으로 구성될 수 있다.

* 순수 비즈니스 로직을 수행하는 API 서버와 그 앞단에 사용자 인증(Authentication), 암호화(SSL), 로드밸런싱 등을 하는 계층을 추가해서 구조상의 유연성을 둘 수 있다.

4. Cacheable (캐시 처리 가능)

* REST는 HTTP라는 기존의 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존의 인프라를 활용 가능하다. 때문에 HTTP 프로토콜 기반의 로드밸런서, SSL, Cache 등을 사용할 수 있다.

* HTTP가 가진 캐싱 기능을 적용할 수 있다. HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.

* 무상태성 API는 많은 양의 입출력 호출을 다루다 보면 Request가 폭증할 수 있다. 때문에 REST API는 Cacheable Data의 저장공간을 확충하도록 설계되어야 한다.

* 즉, 데이터가 Cacheable 할 때, 그 Response는 그 데이터가 언제까지 저장될 수 있다는 것을 지시해야 한다. 이를 통해 API와 인터렉션 수를 드라마틱하게 줄일 수 있다. 또, 내부 서버 사용을 줄여서 빠르고 효율적인 애플리케이션을 만들도록 하는 도구들을 API 사용자들에게 제공한다.

* Cache를 사용하면 REST 컴포넌트가 위치한 서버에 Transation을 발생시키지 않는다. 때문에 전체 응답 시간과 성능, 그리고 서버의 자원 사용률을 비약적으로 향상할 수 있다.

5. Uniform Interface (인터페이스 일관성)

* 서버로부터 클라이언트를 분리하는 것의 핵심은 느슨한 결합으로 애플리케이션의 독립적인 개발을 가능하게 하는 Uniform Interface를 갖는 것이다.

* REST는 HTTP 표준에 따르는 것이라면, 안드로이드든 iOS든, 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용이 가능하며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미한다.

이는 REST 개념이 대두된 배경과도 연관된다.

1. 어플리케이션 복잡도 증가에 따른 어플리케이션 분리 및 통합이 중요해졌다.

2. 모바일과 같은 다양한 클라이언트의 등장으로 Backend 하나로 다양한 Device를 대응하기 위해 REST의 필요성이 늘어났다.

6. Self-descriptiveness (자체 표현 구조)

* 동사(Method) + 명사(URI)로 이루어져 있어 어떤 메서드에서 무슨 행위를 하는지 알 수 있으며, 메시지 포맷 역시 JSON를 이용해서 직관적으로 이해가 가능한 구조

RESTful API - 두 번째 이야기

객체지향 프로그래밍

컴퓨터 프로그래밍 패러다임(견해, 사고법)의 하나로, 프로그래밍에서 필요한 데이터를 추상화시켜 상태(속성, 어트리뷰트)와 행위(메소드)를 가진 객체로 만들고, 그 객체간의 상호작용을 통해 로직을 구성하는 방법

1. 장점

- 다른 클래스를 가져와 사용할 수 있고 상속받을 수 있어 코드의 재사용성 증가

- 절차지향보다 유지보수가 간단

- 클래스 단위의 모듈화가 가능하여 대형 프로젝트에 적합

2. 단점

- 처리속도가 상대적으로 느리다

- 객체가 많으면 용량이 커진다

- 설계시 많은 노력과 시간이 필요하다

3. 키워드

- 클래스 : 현실 세계의 객체를 추상화시켜, 속성과 메소드로 정의한 것 (논리적 개념)

- 인스턴스 : 클래스에서 정의한 것을 토대로 만든 실제 메모리상에 할당된 것, 실제 데이터

- 추상화 : 객체지향 관점에서 클래스를 정의하는 것, 불필요한 정보 외 중요한 정보만 표현하여 공통의 속성과 기능을 묶어 이름을 붙이는 것

- 캡슐화 : 코드를 수정없이 재활용하는 것을 목적으로 함. 클래스라는 캡슐에 기능과 특성을 담아 목적을 기준으로 묶는다. *은닉화와의 차이 - 은닉화는 캡슐화의 일부이며, 목적으로 묶인 캡슐 안을 사용자가 볼 수 없단 것이 은닉화.

- 상속 : 클래스로부터 속성과 메소드를 물려받는 것. 다른 클래스를 가져와서 수정할 일이 있다면, 그 클래스를 직접 수정하는 대신 상속을 받아 변경하고자 하는 부분만 변경

- 다형성 : 하나의 변수명이나 함수명이 상황에 따라서 다르게 해석될 수 있음. 대표적인 다형성이 오버라이딩과 오버로딩

4. 5가지 법칙 - SOLID

- Single Responsibility Principle, 단일 책임 법칙 : 각 클래스는 목적을 하나씩만 가지고 그에 대한 책임을 져야 한다.

- Open Close Principle, 개방 폐쇄 법칙 : 각 클래스는 클래스에 대한 수정을 폐쇄하고, 확장에 대해 개방해야 한다. 즉, 클래스를 수정해야 한다면 그 클래스를 상속, 즉 확장하여 수정한다.

- Liskov Substitusion Principle, 리스코프 치환 법칙 : 자식 클래스를 사용 중일 때, 거기에 부모 클래스로 치환하여도 문제가 없어야 한다.

- Interface Segreation Principle, 인터페이스 분리 법칙 : 각 행위에 대한 인터페이스는 서로 분리되어야 한다. 핸드폰을 예로 들면, 전화를 하는데 핸드폰 카메라가 방해되면 안된다.

- Dependency Inversion Principle, 의존성 역전 법칙 : 상위 클래스가 하위 클래스에 의존하면 안된다는 법칙. 즉 기본적인 공통되는 속성을 하위 클래스에 의존하면 안된다.