포스트

2022-10-14-TIL

2022-10-14-TIL

Today I Learned

Read Timeout

HTTP 클라이언트의 타임아웃은 보통 두 가지로 나뉜다. 연결 타임아웃(connect timeout)은 상대 서버와 연결을 맺기까지 기다리는 시간이고, 읽기 타임아웃(read timeout)은 연결이 맺어진 뒤 데이터를 읽을 때 다음 데이터가 올 때까지 기다리는 시간이다. 자바의 URLConnection Javadoc도 두 값을 이렇게 구분하고, 어느 쪽이든 시간이 지나면 SocketTimeoutException을 던지며 0은 무한 대기를 뜻한다고 적고 있다(URLConnection).

여기서 헷갈리기 쉬운 점은 읽기 타임아웃이 “응답 전체를 받는 데 걸리는 최대 시간”이 아니라는 것이다. 데이터를 읽으려고 기다리는 한 번의 대기에 걸리는 시간 제한이라서, 서버가 데이터를 조금씩 계속 보내면 전체 응답 시간은 읽기 타임아웃보다 길어질 수 있다. 전체 요청 시간을 제한하려면 별도의 타임아웃을 두어야 한다. 그리고 타임아웃 값이 0이면 무한 대기이므로, 외부 API를 호출할 때 값을 지정하지 않으면 상대 서버가 멈췄을 때 호출한 스레드도 같이 묶인다.

  • https://ncucu.me/164
  • https://inyl.github.io/programming/2017/12/02/timeout.html
  • https://d2.naver.com/helloworld/1321

Reactive Programming vs Functional Programming

두 용어는 자주 같이 나오지만 축이 다르다. 함수형 프로그래밍은 순수 함수와 불변 데이터, 함수 조합으로 프로그램을 짜는 방식이다. 리액티브 프로그래밍은 시간에 따라 흘러오는 데이터 스트림과 그 변화에 반응하는 방식이다. 리액티브 라이브러리가 map, filter 같은 함수형 연산자를 스트림에 쓰기 때문에 둘이 섞여 보인다.

리액티브라는 말은 시스템 설계 차원에서도 쓰인다. Reactive Manifesto는 응답성(Responsive), 회복성(Resilient), 탄력성(Elastic), 메시지 기반(Message Driven)을 리액티브 시스템의 특성으로 든다(The Reactive Manifesto). 라이브러리 수준에서는 Reactive Streams가 “non-blocking back pressure”를 갖춘 비동기 스트림 처리 표준을 정했고, JDK 9의 java.util.concurrent.Flow가 이 인터페이스와 의미상 1:1로 대응한다(Reactive Streams).

  • https://bhagyashree9214.medium.com/reactive-programming-vs-functional-programming-4d4d17786abc

Java Call by Reference vs Call by Value

자바는 항상 값으로 전달(call by value)한다. JLS는 메서드가 호출되면 실제 인자 표현식의 값이 새로 만들어진 매개변수 변수를 초기화한다고 정의한다(JLS 8.4.1). 객체를 넘길 때 헷갈리는 이유는, 넘어가는 값이 객체 자체가 아니라 객체를 가리키는 참조 값이기 때문이다(JLS 4.3.1).

1
2
3
4
void rename(User user) {
    user.setName("b");   // 같은 객체를 가리키므로 호출한 쪽에서도 보인다
    user = new User("c"); // 매개변수 변수만 바뀌고 호출한 쪽 변수는 그대로다
}

참조 값을 복사해서 받았으니 그 참조로 객체의 상태를 바꾸면 호출한 쪽에서도 보인다. 하지만 매개변수에 다른 객체를 대입해도 호출한 쪽 변수에는 영향이 없다. call by reference였다면 두 번째 줄도 호출한 쪽 변수를 바꿨어야 한다.

  • https://deveric.tistory.com/92

RESTful API

REST는 Roy Fielding이 박사 논문에서 정의한 아키텍처 스타일이다. 클라이언트-서버, 무상태(stateless), 캐시, 균일한 인터페이스, 계층화 시스템, 코드 온 디맨드(선택)라는 제약을 차례로 더해 정의한다. 무상태 제약은 각 요청이 그 요청을 이해하는 데 필요한 정보를 모두 담아야 하고 서버에 저장된 맥락에 기대면 안 된다는 뜻이다. 균일한 인터페이스는 다시 자원의 식별, 표현을 통한 자원 조작, 자기 서술적 메시지, 하이퍼미디어(HATEOAS)로 나뉜다(Fielding, Chapter 5).

실무에서 “RESTful API”라고 부르는 것은 대개 URI로 자원을 나타내고 HTTP 메서드로 행위를 표현하는 API다. 논문의 제약, 특히 하이퍼미디어까지 지키는 API는 드물다는 점을 알아 두면 REST 논쟁을 읽을 때 도움이 된다.

  • https://aws.amazon.com/ko/what-is/restful-api/
참고한 자료외부 출처 5

외부 출처

이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

댓글

아직 댓글이 없습니다