Optional 클래스는 Integer나 Double 클래스처럼 'T'타입의 객체를 포장해 주는 래퍼 클래스(Wrapper class)입니다.

따라서 Optional 인스턴스는 모든 타입의 참조 변수를 저장할 수 있습니다.

이러한 Optional 객체를 사용하면 예상치 못한 NullPointerException 예외를 제공되는 메소드로 간단히 회피할 수 있습니다.

즉, 복잡한 조건문 없이도 널(null) 값으로 인해 발생하는 예외를 처리할 수 있게 됩니다.

Optional 객체의 생성 of() 메소드나 ofNullable() 메소드를 사용하여 Optional 객체를 생성할 수 있습니다.

of() 메소드는 null이 아닌 명시된 값을 가지는 Optional 객체를 반환합니다.

만약 of() 메소드를 통해 생성된 Optional 객체에 null이 저장되면 NullPointerException 예외가 발생합니다.

따라서 만약 참조 변수의 값이 만에 하나 null이 될 가능성이 있다면, ofNullable() 메소드를 사용하여 Optional 객체를 생성하는 것이 좋습니다.

ofNullable() 메소드는 명시된 값이 null이 아니면 명시된 값을 가지는 Optional 객체를 반환하며, 명시된 값이 null이면 비어있는 Optional 객체를 반환합니다.

Optional opt = Optional.ofNullable("자바 Optional 객체");

System.out.println(opt.get());

실행 결과 자바 Optional 객체

Optional 객체에 접근 get() 메소드를 사용하면 Optional 객체에 저장된 값에 접근할 수 있습니다.

만약 Optional 객체에 저장된 값이 null이면, NoSuchElementException 예외가 발생합니다.

따라서 get() 메소드를 호출하기 전에 isPresent() 메소드를 사용하여 Optional 객체에 저장된 값이 null인지 아닌지를 먼저 확인한 후 호출하는 것이 좋습니다.

다음 예제는 isPresent() 메소드를 이용하여 좀 더 안전하게 Optional 객체에 저장된 값에 접근하는 예제입니다.

Optional<String> opt = Optional.ofNullable("자바 Optional 객체");

 

if(opt.isPresent()) {

    System.out.println(opt.get());

}

실행 결과 자바 Optional 객체

또한, 다음과 같은 메소드를 사용하여 null 대신에 대체할 값을 지정할 수도 있습니다.

1. orElse() 메소드 : 저장된 값이 존재하면 그 값을 반환하고, 값이 존재하지 않으면 인수로 전달된 값을 반환함.

2. orElseGet() 메소드 : 저장된 값이 존재하면 그 값을 반환하고, 값이 존재하지 않으면 인수로 전달된 람다 표현식의 결괏값을 반환함.

3. orElseThrow() 메소드 : 저장된 값이 존재하면 그 값을 반환하고, 값이 존재하지 않으면 인수로 전달된 예외를 발생시킴.

Optional<String> opt = Optional.empty(); // Optional를 null로 초기화함.

System.out.println(opt.orElse("빈 Optional 객체"));
System.out.println(opt.orElseGet(String::new));

실행 결과 빈 Optional 객체

위의 예제에서 사용된 empty() 메소드는 Optional 객체를 null로 초기화해줍니다.

기본 타입의 Optional 클래스 자바에서는 IntStream 클래스와 같이 기본 타입 스트림을 위한 별도의 Optional 클래스를 제공하고 있습니다.

1. OptionalInt 클래스

2. OptionalLong 클래스

3. OptionalDouble 클래스

이러한 클래스는 반환 타입이 Optional 타입이 아니라 해당 기본 타입이라는 사실만 제외하면 거의 모든 면에서 비슷합니다.

또한, Optional 객체에서 get() 메소드를 사용하여 저장된 값에 접근할 수 있는 것처럼 클래스별로 저장된 값에 접근할 수 있는 다음과 같은 메소드를 제공하고 있습니다.

클래스 저장된 값에 접근하는 메소드 Optional T get() OptionalInt int getAsInt() OptionalLong long getAsLong() OptionalDouble double getAsDouble()

예제 IntStream stream = IntStream.of(4, 2, 1, 3);

OptionalInt result = stream.findFirst();

System.out.println(result.getAsInt());

4

Optional 클래스의 메소드는 다음과 같습니다.

메소드 설명 static <T> Optional<T> empty() 아무런 값도 가지지 않는 비어있는 Optional 객체를 반환함. T get() Optional 객체에 저장된 값을 반환함.

boolean isPresent() 저장된 값이 존재하면 true를 반환하고, 값이 존재하지 않으면 false를 반환함.

static <T> Optional<T> of(T value) null이 아닌 명시된 값을 가지는 Optional 객체를 반환함.

static <T> Optional<T> ofNullable(T value) 명시된 값이 null이 아니면 명시된 값을 가지는 Optional 객체를 반환하며, 명시된 값이 null이면 비어있는 Optional 객체를 반환함.

T orElse(T other) 저장된 값이 존재하면 그 값을 반환하고, 값이 존재하지 않으면 인수로 전달된 값을 반환함.

T orElseGet(Supplier<? extends T> other) 저장된 값이 존재하면 그 값을 반환하고, 값이 존재하지 않으면 인수로 전달된 람다 표현식의 결괏값을 반환함.

<X extends Throwable> T orElseThrow(Supplier<? extends X> exceptionSupplier) 저장된 값이 존재하면 그 값을 반환하고, 값이 존재하지 않으면 인수로 전달된 예외를 발생시킴.

• 자바 커뮤니티에서는 클로저와 람다를 혼용하면서 개념 상 혼란이 있었습니다. 그래서 자바 8부터 클로저를 지원한다는 글을 보기도 합니다.
• 자바에서의 람다와 클로저를 명확히 구분해보고자 합니다.

• 보통의 함수는 외부에서 인자를 받아서 로직을 처리합니다.

• 그런데 클로저는 자신을 둘러싼 context 내의 변수에 접근할 수 있습니다.

• 즉, 외부 범위의 변수를 함수 내부로 바인딩하는 기술입니다.

• 특이한 점은 자신을 둘러싼 외부 함수가 종료되더라도 이 값이 유지가 됩니다.

• 함수에서 사용하는 값들은 클로저가 생성되는 시점에서 정의되고 함수 자체가 복사되어 따로 존재하기 때문입니다.

function add(x)
  function addX(y)
    return y + x
  return addX

• 함수 addX 내부에서 x 는 현재 함수를 둘러싸고 있는 외부 컨텍스트에 존재합니다.
• add 에서 이 함수가 리턴되는데 x 의 값(value)이나 참조(reference)를 복사한 클로저가 리턴됩니다.
• 함수를 일급 객체 (first-class citizens) 로 취급하는 언어에서는 이를 변수로 받아서 사용이 가능합니다.
• 넣어주는 x 값에 따라 함수가 생성되는 것을 볼 수 있습니다.

variable add1 = add(1) // return y + 1
variable add5 = add(5) // return y + 5

assert add1(3) = 4
assert add5(3) = 8

• 그렇다면 자바에서의 클로저는 어떨까요? 클래스 내부의 필드에 접근하는 메소드를 생각해봅시다.
• 이미 자바에서는 클로저가 있습니다. 메소드 내에서 외부 컨텍스트의 변수를 참조하기 때문이죠. 하지만 메소드는 함수가 아니고, 일급 객체도 아닙니다.

자바에서의 클로저 예제를 살펴보겠습니다.

public class ClosureTest {
  private Integer b = 2;
  
  private Stream<Integer> calculate(Stream<Integer> stream, Integer a) {
    return stream.map(t -> t * a + b);
  }

  public static void main(String... args) {
    
    List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
    List<Integer> result = new ClosureTest()
      .calculate(list.stream(), 3)
      .collect(Collectors.toList());
    System.out.println(result); // [5, 8, 11, 14, 17]
  }
}

• calculate 메소드에서 map 메소드를 호출하고 있습니다. 여기서 인자로 넘어가는 람다가 있는데 내부에서 외부 변수인 a와 b를 참조하고 있습니다. 이 때 a 와 b 는 컴파일러가 final 로 간주합니다. 내부에서 필요로 하는 정보를 넘길 때 값이 변경되면 의도하지 않은 결과가 나올 수 있기 때문에, 해당 값은 변하지 않아야 합니다. 따라서 컴파일러는 해당 값을 상수로 취급하는 거죠. 이전 포스트에서 유사 파이널(effectively final)을 살펴봤었죠. 따라서 값을 변경하려고 하면 다음과 같은 컴파일 에러를 볼 수 있습니다.

private Stream<Integer> calculate(Stream<Integer> stream, Integer a) {
  a = 10; // 값 변경 불가
  // Variable used in lambda expression should be final or effectively final
  return stream.map(t -> t * a + b);
}

이를 우회하는 방법은 이전 포스트에서 살펴본 것처럼 객체를 이용하면 됩니다. 객체를 사용하기 위해서 다음과 같이 예제를 변경해보겠습니다.

public class ClosureTest {
  private Integer b = 2;

  private Integer getB() {
    return b;
  }

  private Stream<Integer> calculate(Stream<Integer> stream, Int a) {
    a.setValue(10); // 값 변경 가능
    return stream.map(t -> t * a.value + getB());
  }
}

class Int {
  public int value;
  public Int(int value) {
    this.value = value;
  }
  public void setValue(int value) {
    this.value = value;
  }
}

• 그렇게 되면 참조값이 final 이기 때문에 객체 안의 값은 변경할 수 있게 됩니다.

public static void main(String... args) {

  List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
  List<Integer> result = new ClosureTest()
    .calculate(list.stream(), new Int(3))
    .collect(Collectors.toList());
  System.out.println(result); // [12, 22, 32, 42, 52]
}

• 하지만 이는 side effect 를 발생시킬 수 있어 위험한 방법입니다.

• 람다와 클로저는 모두 익명의 특정 기능 블록입니다. 차이점은 클로저는 외부 변수를 참조하고, 람다는 매개변수만 참조한다는 겁니다.

// Lambda.
(server) -> server.isRunning();

// Closure. 외부의 server 라는 변수를 참조
() -> server.isRunning();

• 클로저는 외부에 의존성이 있고, 람다는 외부에 의존성이 없는 스태틱 메소드와 비슷합니다.

다음 예제는 폴링 후 조건에 따라 대기하는 메소드입니다. Predicate 를 이용해 검증하고 결과에 따라 짧은 시간 동안 멈춥니다.

static <T> void waitFor(T input, Predicate<T> predicate) throws InterruptedException {
  while (!predicate.test(input)) {
    Thread.sleep(250);
  }
}

어떤 HTTP 서버가 구동 중인지 확인하는 간단한 람다를 넘겨보겠습니다. 이때 매개변수를 참조하고 있기 때문에 그 외의 외부 변수에 대한 참조가 없죠. 런타임에 제공하는 서버 변수를 컴파일러가 참고할 필요가 없는 람다입니다. 외부 변수에 영향이 없기 때문에 더 효율적으로 동작합니다.

waitFor(new HttpServer(), (server) -> !server.isRunning());
waitFor(new HttpServer(), HttpServer::isRunning); // 메소드 참조

이번엔 동일한 로직을 클로저를 이용해 구현해보겠습니다. 인자 없이 boolean 값을 리턴하는 함수형 인터페이스를 하나 만듭니다.

static <T> void waitFor(Condition condition) throws InterruptedException {
  while (!condition.isSatisfied()) {
    Thread.sleep(250);
  }
}

@FunctionalInterface
interface Condition {
  boolean isSatisfied();
}

받아오는 정보가 없기 때문에 여기서는 판단에 필요한 정보를 외부에서 참조해야한다는 것을 알 수 있습니다. 이 변수는 컴파일러에 의해 복사됩니다. 이것은 클로저입니다.

void closure() throws InterruptedException {
  HttpServer server = new HttpServer();
  waitFor(() -> !server.isRunning());
}

자바에서 클로저는 함수의 인스턴스입니다. 람다가 스태틱 메소드와 비슷하다면 외부 변수를 참조하는 익명 클래스가 클로저와 비슷하다고 볼 수 있습니다.

void anonymousClassClosure() throws InterruptedException {
  HttpServer server = new HttpServer();
  waitFor(new Condition() {
    @Override
    public boolean isSatisfied() {
      return !server.isRunning();
    }
  });
}

설명이 길었는데, 결론은 람다는 클로저를 포함하는 더 큰 개념이라고 볼 수 있습니다. 람다가 자신의 범위 밖에 있는 변수를 사용하면 그것은 람다인 동시에 클로저입니다.

• Spring Framework 5.0은 2013 년 12 월 버전 4가 출시 된 이후 Spring Framework의 첫 번째 주요 릴리스입니다. Spring Framework 프로젝트 책임자 인 Juergen Hoeller 는 2016 년 7 월 28 일에 첫 번째 Spring Framework 5.0 마일스톤 (5.0 M1)을 발표했습니다 .

• 이제 거의 1 년 후, 릴리스 후보 3 (RC3)이 2017 년 7 월 18 일에 릴리스 될 예정입니다. 이것은 Spring Framework의 첫 번째 GA (일반 가용성) 릴리스 에 대한 로드맵 의 최종 릴리스가 될 것으로 예상됩니다.

• 높은 수준에서 Spring Framework 5.0의 기능은 다음과 같이 분류 할 수 있습니다.

• JDK 기준 업데이트.
• 핵심 프레임 워크 개정.
• 핵심 컨테이너 업데이트.
• Kotlin을 사용한 함수형 프로그래밍.
• 반응형 프로그래밍 모델.
• 테스트 개선.
• 라이브러리 지원.
• 지원 중단.

• 전체 Spring Framework 5.0 코드베이스는 Java 8에서 실행됩니다. 따라서 Java 8은 Spring Framework 5.0에서 작동하기위한 최소 요구 사항입니다.

• 이것은 실제로 프레임 워크에서 매우 중요합니다. 개발자로서 우리는 최신 Java 릴리스에있는 모든 새로운 기능을 즐길 수 있었습니다. 프레임 워크 자체는 더 이상 사용되지 않는 Java 릴리스를 지원하는 데 많은 짐을 싣고있었습니다.

• 원래 Spring Framework 5.0은 Java 9에서 릴리스 될 예정이었습니다. 그러나 Java 9 릴리스가 18 개월 늦게 실행되면서 Spring 팀 은 Spring Framework 5.0 릴리스를 Java 9에서 분리하기로 결정했습니다. 그러나 Java 9가 출시되면 ( 2017 년 9 월 예정 ) Spring Framework 5.0이 준비됩니다.

• 핵심 Spring Framework 5.0은 Java 8에 도입 된 새로운 기능을 활용하도록 수정되었습니다. 핵심 기능은 다음과 같습니다.

• Java 8 리플렉션 향상을 기반으로 Spring Framework 5.0의 메서드 매개 변수에 효율적으로 액세스 할 수 있습니다.

• Core Spring 인터페이스는 이제 Java 8 기본 메소드에 빌드 된 선택적 선언을 제공합니다.

• @Nullable 및 @NotNull 주석 명시 적으로 널 (NULL) 인수와 반환 값을 표시합니다. 이렇게하면 런타임에 NullPointerException을 발생시키는 대신 컴파일 타임에 null 값을 처리 할 수 ​​있습니다.

• 로깅 측면에서 Spring Framework 5.0은 표준 Commons Logging 대신 spring-jcl이라는 Commons Logging 브리지 모듈과 함께 기본 제공됩니다. 또한이 새 버전은 추- 가 브리지없이 Log4j 2.x, SLF4J, JUL (java.util.logging)을 자동으로 감지합니다.

• 방어 프로그래밍은 또한 getFile 메소드에 대한 isFile 표시기를 제공하는 Resource 추상화로 추진력을 얻습니다.

• Spring Framework 5.0은 이제 클래스 경로 스캔의 대안으로 후보 컴포넌트 인덱스를 지원합니다. 이 지원은 클래스 경로 스캐너에서 후보 구성 요소 식별 단계를 바로 가기 위해 추가되었습니다.
• 색인을 생성하려면 각 모듈에 아래의 의존성을 추가하기만 하면됩니다. 이 프로세스는 인덱스 스캔에 포함될 META-INF / spring.components 파일을 생성합니다.

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context-indexer</artifactId>
        <version>5.0.3.RELEASE</version>
        <optional>true</optional>
    </dependency>
</dependencies>

• 애플리케이션 빌드 태스크는 현재 프로젝트에 대한 자체 META-INF / spring.components 파일을 정의 할 수 있습니다. 컴파일 시간에 소스 모델이 검사되고 JPA 엔티티와 Spring 컴포넌트가 플래그됩니다.

• 클래스 경로를 스캔하지 않고 색인에서 항목을 읽는 것은 클래스가 200 개 미만인 소규모 프로젝트의 경우 큰 차이가 없습니다. 그러나 대규모 프로젝트에는 상당한 영향을 미칩니다. 구성 요소 인덱스를로드하는 것은 저렴합니다. 따라서 인덱스를 사용한 시작 시간은 클래스 수가 증가함에 따라 일정하게 유지됩니다.

• 이것이 우리 개발자에게 의미하는 바는 대규모 Spring 프로젝트에서 애플리케이션의 시작 시간이 크게 단축된다는 것입니다. 20 초 또는 30 초는 그리 많지 않은 것 같지만 하루에 수십 또는 수백 번 그 시간을 기다리면 더해집니다. 구성 요소 인덱스를 사용하면 일일 생산성에 도움이됩니다.

• Spring의 Jira 에서 컴포넌트 인덱스 기능에 대한 자세한 정보를 찾을 수 있습니다 .

@GetMapping("/")
public String hello(@RequestParam @Nullable String name) {
  return "hello " + name + "!";
}

@Bean
ApplicationRunner applicationRunner(@Nullable PersonService personService) {
  return args -> {
  };
}

• 이제 @Nullable 주석을 선택적 주입 지점에 대한 표시기로 사용할 수도 있습니다. @Nullable을 사용하면 소비자에게 값이 null이되도록 준비해야하는 의무가 부과됩니다. 이렇게하면 런타임에 NullPointerException을 발생시키는 대신 컴파일 타임에 null 값을 처리 할 수 ​​있습니다.

• 기능적인 프로그래밍 스타일의 구현 GenericApplicationContext 및 AnnotationConfigApplicationContext.
• 인터페이스 메서드에서 트랜잭션, 캐싱 및 비동기 주석을 일관되게 감지합니다.
• XML 구성 네임 스페이스는 버전없는 스키마로 간소화되었습니다.

• Spring Framework 5.0은 JetBrains Kotlin 언어를 지원 합니다. Kotlin은 함수형 프로그래밍 스타일을 지원하는 객체 지향 언어입니다. Kotlin은 JVM 위에서 실행되지만 이에 국한되지는 않습니다.

• Kotlin 지원을 통해 개발자는 기능적인 Spring 프로그래밍, 특히 기능적인 웹 엔드 포인트 및 빈 등록에 뛰어들 수 있습니다.

• Spring Framework 5.0에서는 다음과 같이 웹 기능 API를위한 깔끔하고 관용적 인 Kotlin 코드를 작성할 수 있습니다.

{
( "/ movie"  및  수락 ( TEXT_HTML )). nest {
GET ( "/" , movieHandler :: findAllView )
GET ( "/ {card}" , movieHandler :: findOneView )
}
( "/ api / movie"  및  수락 ( APPLICATION_JSON )). nest {
GET ( "/" , movieApiHandler :: findAll )
GET ( "/ {id}" , movieApiHandler :: findOne )
}
}

빈 등록의 경우 XML 또는 @Configuration 및 대신 @BeanKotlin을 사용하여 다음과 같이 Spring Bean을 등록 할 수 있습니다.

val  context  =  GenericApplicationContext {
registerBean ()
registerBean { Cinema ( it . getBean ())}
}

• 이번 Spring 릴리스의 흥미로운 기능은 새로운 반응 스택 웹 프레임 워크입니다. 완전 반응적이고 비 차단적인이 스택은 적은 수의 스레드로 확장 할 수있는 이벤트 루프 스타일 처리에 적합합니다.

• Reactive Streams 는 Netflix, Pivotal, Typesafe, Red Hat, Oracle, Twitter 및 Spray.io의 엔지니어가 개발 한 API 사양입니다. 이것은 JPA가 API이고 Hibernate가 구현 인 Hibernate 용 JPA처럼 구현할 반응 형 프로그래밍 구현을위한 공통 API를 제공합니다.

• Reactive Streams API는 공식적으로 Java 9의 일부입니다. Java 8에서는 Reactive Streams API 사양에 대한 종속성을 포함해야합니다.

• Spring Framework 5.0의 스트리밍 지원 은 Reactive Streams API 사양을 구현하는 Project Reactor를 기반으로 합니다.

• Spring Framework 5.0에는 반응 형 HTTP 및 WebSocket 클라이언트를 지원하는 새로운 spring-webflux 모듈이 있습니다. Spring Framework 5.0은 REST, HTML 및 WebSocket 스타일 상호 작용을 포함하는 서버에서 실행되는 반응 형 웹 애플리케이션에 대한 지원도 제공합니다.

• spring-webflux의 서버 측에는 두 가지 프로그래밍 모델이 있습니다.

  • @Controller Spring MVC의 주석 기반 및 기타 주석.
  • Java 8 람다를 사용한 기능적 스타일 라우팅 및 처리.

@GetMapping("/{id}")
private Mono<Employee> getEmployeeById(@PathVariable String id) {
    return employeeRepository.findEmployeeById(id);
}

@GetMapping
private Flux<Employee> getAllEmployees() {
    return employeeRepository.findAllEmployees();
}

• RestTemplate 의 대안으로 Spring 에서는 WebClient 사용을 강력히 권고하고 있으며 다음과 같은 특징을 가지고 있습니다.
  • Non-blocking I/O
  • Reactive Streams back pressure
  • High concurrency with fewer hardware resources
  • Functional-style, fluent API that takes advantage of Java 8 lambdas
  • Synchronous and asynchronous interactions
  • Streaming up to or streaming down from a server
  • Spring 5.0에서 REST 엔드 포인트의 WebClient 구현은 다음과 같습니다.
  • (Non-Blocking I/O 기반의 Asynchronous API)
  • (WebClient는 Blocking I/O 기반의 Synchronous API 방식의 restTemplate 대안으로 사용 가능.)
  • 출처: https://ict-nroo.tistory.com/119 [개발자의 기록습관]

@Service
@RequiredArgsConstructor
@Slf4j
public class SomeService implements SomeInterface {

    private final WebClient webClient;
    public Mono<SomeData> getSomething() {
  
    return webClient.mutate()
                    .build()
                    .get()
                    .uri("/resource")
                    .retrieve()
                    .bodyToMono(SomeData.class);
    }
}

새로운 WebFlux 모듈은 우리에게 몇 가지 흥미로운 새로운 기능을 제공하지만, 전통적인 Spring MVC는 여전히 Spring Framework 5.0에서 완벽하게 지원됩니다.

• Spring Framework 5.0은 JUnit 5 에서 테스트 및 확장을 작성하기 위해 JUnit 5 Jupiter 를 완벽하게 지원합니다 . 프로그래밍 및 확장 모델을 제공하는 것 외에도 Jupiter 하위 프로젝트는 Spring에서 Jupiter 기반 테스트를 실행하기위한 테스트 엔진을 제공합니다.

JUnit 5 개선사항 참고 : https://javacan.tistory.com/entry/JUnit-5-Intro

• JUnit 4가 단일 jar였던 것에 비해, JUnit 5는 크게 JUnit Platform, JUnit Jupiter, JUnit Vintage 모듈로 구성되어 있다.

• 테스트 작성자를 위한 API 모듈과 테스트 실행을 위한 API가 분리되어 있다.

  • 예를 들어, JUnit Jupiter는 테스트 코드 작성에 필요한 junit-jupiter-api 모듈과 테스트 실행을 위한 junit-jupiter-engine 모듈로 분리되어 있다.

• 자바 8 또는 그 이상 버전을 요구한다.

• 또한 Spring Framework 5는 Spring TestContext Framework에서 병렬 테스트 실행을 지원합니다.

• 반응 형 프로그래밍 모델의 경우 spring-test는 이제 Spring WebFlux에 대한 테스트 지원을 통합하기위한 WebTestClient를 포함합니다. MockMvc와 유사한 새로운 WebTestClient에는 실행중인 서버가 필요하지 않습니다. 모의 요청 및 응답을 사용하여 WebTestClient는 WebFlux 서버 인프라에 직접 바인딩 할 수 있습니다.

• 물론 Spring Framework 5.0은 여전히 ​​우리의 오랜 친구 인 JUnit 4도 지원합니다! 글을 쓰는 시점에서 JUnit 5는 곧 출시 될 예정입니다. JUnit 4에 대한 지원은 향후 한동안 Spring Framework에서 지원 될 것입니다.

Spring Framework 5.0은 이제 다음과 같은 업그레이드 된 라이브러리 버전을 지원합니다.

• Jackson 2.6 이상
• EhCache 2.10+ / 3.0 GA
• 최대 절전 모드 5.0 이상
• JDBC 4.0 이상
• XmlUnit 2.x 이상
• OkHttp 3.x 이상
• Netty 4.1 이상

API 수준에서 Spring Framework 5.0은 다음 패키지에 대한 지원을 중단했습니다.

• beans.factory.access

• jdbc.support.nativejdbc

• mock.staticmock spring-aspects 모듈의.

• web.view.tiles2M. 이제 Tiles 3이 최소 요구 사항입니다.

• orm.hibernate3 및 orm.hibernate4. 이제 Hibernate 5가 지원되는 프레임 워크입니다.

• Spring Framework 5.0은 다음 라이브러리에 대한 지원도 중단했습니다.

• 포틀릿.

• 속도.

• JasperReports.

• XMLBeans.

• JDO.

• 구아바. 이전 패키지를 사용하는 경우 Spring Framework 4.3.x를 유지하는 것이 좋습니다.

Spring Framework 5.0의 하이라이트는 분명 리 액티브 프로그래밍이며 이는 중요한 패러다임 전환입니다. Spring Framework 5.0을 리 액티브 프로그램의 초석 릴리스로 볼 수 있습니다. 나머지 2017 년과 그 이후에는 하위 프로젝트가 반응 기능을 구현하는 것을 볼 수 있습니다. SpringData, Spring Security, Spring Integration 등의 향후 릴리스에 추가 된 반응 형 프로그래밍 기능을 볼 수 있습니다.

• 데이터의 일관성을 보장하기 위한 방법입니다. 오라클과 같이 고가의 DBMS를 사용하는 이유가 데이터의 무결성과 일관성을 유지하는 능력이 뛰어나기 때문입니다.

Lock은 상황에 따라서 크게 두가지로 나누어 집니다.

• 보통 데이터를 읽을 때 사용합니다. 원하는 데이터에 lock을 걸었지만 다른 세션에서 읽을 수 있습니다.
• 공유Lock을 설정한 경우 추가로 공유Lock을 설정할 수 있지만, 배타적 Lock은 설정할 수 없습니다.
• 즉, 내가 보고 있는 데이터는 다른 사용자가 볼 수 있지만, 변경할 수는 없습니다.

• 어떤 트랜잭션에서 데이터를 변경하고자 할 때(ex . 쓰고자 할 때) 해당 트랜잭션이 완료될 때까지 해당 테이블 혹은 레코드(row)를 다른 트랜잭션에서 읽거나 쓰지 못하게 하기 위해 Exclusive lock을 걸고 트랜잭션을 진행시키는것입니다.
• 보통 데이터를 변경할 때 사용합니다.
• 이름에서 느껴지는 것 처럼 해당 Lock이 해제되기 전까지는, 다른 공유Lock, 배타적Lock을 설정할 수 없습니다.
• 즉, 읽기 기와 쓰기가 불가능하다는 의미입니다.

경합으로 인한 상태인 블로킹에 대하여 알아봅니다.

블로킹은 Lock들의 경합(Race condition이라고도 합니다)이 발생하여 특정 세션이 작업을 진행하지 못하고 멈춰 선 상태를 의미합니다. 공유Lock과 배타적Lock 또는 배타적Lock과 배타적Lock끼리 블로킹이 발생할 수 있습니다. 이를 해결하는 방법은 Transaction commit 또는 rollback 뿐입니다. 경합이 발생할 때, 먼저 Lock을 설정한 트랜젝션을 기다려야하기 때문에, 이런 현상이 반복되면 빠른 서비스를 제공할 수 없습니다.

SQL 문장에 가장 빠르게 실행되도록 리펙토링하는 것이 가장 기본이며 효과적인 방법입니다. 트랜젝션을 가능한 짧게 정의하면 경합을 줄일 수 있습니다. 동일한 데이터를 동시에 변경하는 작업을 하지 않도록 설계하는 것이 좋습니다. 또한 트랜젝션이 활발한 주간에는 대용량 갱신 작업을 수행하면 안됩니다. 대용량작업이 불가피할 경우, 작업단위를 쪼개거나 lock_timeout을 설정하여 해당 Lock의 최대시간을 설정할 수 있습니다.

set lock_timeout 3000

• deadlock은 트랜젝션간의 교착상태를 의미합니다. 두개의 트랜젝션간에 각각의 트랜젝션이 가지고 있는 리소스의 Lock을 획득하려고 할 때 발생합니다.
  

• 가장 흔히 떠올릴 수 있는 deadlock 상황입니다. 1번 트랜젝션에서 2번 리소스의 잠금을 획득, 2번 트랜젝션에서는 1번 리소스의 잠금을 획득한 상태입니다.

• 이때, 동시에 상대방의 데이터를 엑세스하려고 할때 기존의 Lock이 해제될 때까지 기다리게 되는 상황입니다.

• Postgresql에서는 자동적으로 deadlock을 인지하고 교착상태를 해결하기 위하여 하나의 트랜젝션을 취소시킵니다. 그러나, 어떤 트랜젝션이 취소될 지 판단하기는 어렵습니다.

• SQL 명령어에 따라서 Lock의 설정대상이 데이터 row일지 database일지 나누어집니다.

1. Row level: 변경하려는 row에만 lock을 설정하는 것을 의미합니다.
2. Page level: 변경하려는 row가 담긴 데이터 page (또는 인덱스 페이지)에 lock을 설정합니다. 같은 페이지에 속한 row들은 변경작업과 무관하게 모두 lock에 의해 잠깁니다. Tabel level: 테이블과 인덱스에 모두 잠금을 설정합니다. Select table, Alter table, Vacuum, Refresh, Index, Drop, Truncate 등의 작업에서 해당레벨의 락이 설정됩니다.
3. Database level: 데이터베이스를 복구하거나 스키마를 변경할 때 발생합니다.

• Lock 리소스가 임계치를 넘으면 Lock 레벨이 확장되는 것을 의미합니다.
• Lock 레벨이 낮을 수록 동시성이 좋아지지만, 관리해야할 Lock이 많아지기 때문에 메모리 효율성은 떨어집니다.
• 반대로 Lock레벨이 높을 수록 관리리소스는 낮지만, 동시성은 떨어집니다.

출처

“Representational State Transfer” 의 약자 자원을 **이름(자원의 표현)**으로 구분하여 해당 자원의 **상태(정보)**를 주고 받는 모든 것을 의미한다. 즉, 자원(resource)의 표현(representation) 에 의한 상태 전달

• 자원(resource)의 표현(representation) 자원: 해당 소프트웨어가 관리하는 모든 것 -> Ex) 문서, 그림, 데이터, 해당 소프트웨어 자체 등 자원의 표현: 그 자원을 표현하기 위한 이름 -> Ex) DB의 학생 정보가 자원일 때, ‘students’를 자원의 표현으로 정한다.
• 상태(정보) 전달 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달한다. JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
• 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식 REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다. REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다. REST의 구체적인 개념 HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다. 즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다. 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
• CRUD Operation Create : 생성(POST) Read : 조회(GET) Update : 수정(PUT) Delete : 삭제(DELETE) HEAD: header 정보 조회(HEAD)

장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

• 표준이 존재하지 않는다.
• 사용할 수 있는 메소드가 4가지 밖에 없다.
• HTTP Method 형태가 제한적이다.
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지더 어렵게 느껴진다.
• 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다.
• PUT, DELETE를 사용하지 못하는 점
• pushState를 지원하지 않는 점

• ‘애플리케이션 분리 및 통합’
• ‘다양한 클라이언트의 등장’
• 최근의 서버 프로그램은 다양한 브라우저와 안드로이폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다. 이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과, REST에 관심을 가지게 되었다.

• 자원(Resource): URI 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다. 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 다. Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
• 행위(Verb): HTTP Method HTTP 프로토콜의 Method를 사용한다. HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.
• 표현(Representation of Resource) Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다. REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다. JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

1. Server-Client(서버-클라이언트 구조) 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다. REST Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다. Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다. 서로 간 의존성이 줄어든다.
2. Stateless(무상태) HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다. Client의 context를 Server에 저장하지 않는다. 즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다. Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다. 각 API 서버는 Client의 요청만을 단순 처리한다. 즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안된다. 물론 이전 요청이 DB를 수정하여 DB에 의해 바뀌는 것은 허용한다. Server의 처리 방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아진다.
3. Cacheable(캐시 처리 가능) 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다. 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다. HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다. 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다. 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다.
4. Layered System(계층화) Client는 REST API Server만 호출한다. REST Server는 다중 계층으로 구성될 수 있다. API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다. 또한 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있다. PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.
5. Code-On-Demand(optional) Server로부터 스크립트를 받아서 Client에서 실행한다. 반드시 충족할 필요는 없다.
6. Uniform Interface(인터페이스 일관성) URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다. 특정 언어나 기술에 종속되지 않는다.

API(Application Programming Interface)란

• 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호 작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것

REST 기반으로 서비스 API를 구현한 것 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.

사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다. REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다. 즉, REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.

참고 리소스 원형

도큐먼트 : 객체 인스턴스나 데이터베이스 레코드와 유사한 개념 컬렉션 : 서버에서 관리하는 디렉터리라는 리소스 스토어 : 클라이언트에서 관리하는 리소스 저장소 URI는 정보의 자원을 표현해야 한다.

resource는 동사보다는 명사를, 대문자보다는 소문자를 사용한다. resource의 도큐먼트 이름으로는 단수 명사를 사용해야 한다. resource의 컬렉션 이름으로는 복수 명사를 사용해야 한다. resource의 스토어 이름으로는 복수 명사를 사용해야 한다. Ex) GET /Member/1 -> GET /members/1 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다. URI에 HTTP Method가 들어가면 안된다. Ex) GET /members/delete/1 -> DELETE /members/1 URI에 행위에 대한 동사 표현이 들어가면 안된다. (즉, CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.) Ex) GET /members/show/1 -> GET /members/1 Ex) GET /members/insert/2 -> POST /members/2

경로 부분 중 변하는 부분은 유일한 값으로 대체한다.(즉, :id는 하나의 특정 resource를 나타내는 고유값이다.) Ex) student를 생성하는 route: POST /students Ex) id=12인 student를 삭제하는 route: DELETE /students/12

슬래시 구분자(/ )는 계층 관계를 나타내는데 사용한다. Ex) http://restapi.example.com/houses/apartments URI 마지막 문자로 슬래시(/ )를 포함하지 않는다. URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다. REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다. Ex) http://restapi.example.com/houses/apartments/ (X) 하이픈(- )은 URI 가독성을 높이는데 사용 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다. 밑줄(_ )은 URI에 사용하지 않는다. 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다. URI 경로에는 소문자가 적합하다. URI 경로에 대문자 사용은 피하도록 한다. RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문 파일확장자는 URI에 포함하지 않는다. REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다. Accept header를 사용한다. Ex) http://restapi.example.com/members/soccer/345/photo.jpg (X) Ex) GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O) 리소스 간에는 연관 관계가 있는 경우 /리소스명/리소스 ID/관계가 있는 다른 리소스명 Ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)

참고 응답상태코드

1xx : 전송 프로토콜 수준의 정보 교환 2xx : 클라어인트 요청이 성공적으로 수행됨 3xx : 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함 4xx : 클라이언트의 잘못된 요청 5xx : 서버쪽 오류로 인한 상태코드

RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다. ‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다. RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다. 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.

이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것 RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.

Ex1) CRUD 기능을 모두 POST로만 처리하는 API Ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName) https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html