Requestor 1.4.0

This release introduces Certificate-Based Authentication in Requestor. This feature supports SSL/TLS certificate authentication to ensure secure communication over networks.

Highlights:

• SSL/TLS Configuration: Automate SSL context setup using file paths or InputStreams for certificates.
• Enhanced Security: Offers both file-based and stream-based certificate handling, along with the robust TLSv1.2 protocol.
• Customizable Trust Management: Allows integration with TrustPolicy for tailored SSL negotiations.

Quick Start:

// File-based certificate authentication
session.req("/api/secure-endpoint").auth(new CertAuth("/path/to/cert.pem", "password"));

// InputStream-based authentication
InputStream certStream = new FileInputStream("/path/to/cert.pem");
session.req("/api/secure-endpoint").auth(new CertAuth(certStream, "password"));

// Using custom TrustPolicy
TrustPolicy myTrustPolicy = new CustomTrustPolicy();
session.req("/api/secure-endpoint").auth(new CertAuth("/path/to/cert.pem", "password", myTrustPolicy));

For more details, refer to our Documentation.

Requestor 1.3.0

[core] Map deserialization in request calls

Now we are able to request to deserialize the response to a map like below.

session.get("endpoint", Map.class, String.class, String.class)

[gson] GsonSerializer

The auto-generated serializers based on Gson were replaced by a universal GsonSerializer that is capable to serialize and deserialize any json object to any java type.

[ktln] CoroutineAsyncRunner

Requestor now provides an extension to better integrate the library with Kotlin. The first implemented feature is the CoroutineAsyncRunner, an async runner that allows requestor sessions to run asynchronous jobs using the provided coroutine context.

Requestor 1.2.1

This release brings a few other improvements to Store as part of the 1.2.x version:

1. The remove method signature was refactored to return the removed Data* object instead of a boolean.
2. The retrieve method was renamed to getValue. The old method name is still available, though, as deprecated. It'll be removed in the next version (1.3.0).
3. The Data getData(String key) method was added to allow retrieving the Data* object of a key, in addition to the getValue method that returns directly the stored value.
4. Two methods were added to refresh data saved in the store:
   4.1. Data refresh(String key, long ttl): refreshes the data associated with the given key, according to the informed TTL (in milliseconds). It returns the refreshed Data* object.
   4.2. Data refresh(String key): refreshes the data associated with the given key, according to the original TTL of the data. It returns the refreshed Data* object.
5. A new clear(boolean fireRemovedEvent) method was added to allow removing all data from the store without triggering the onRemoved handlers by setting the boolean parameter to false. By default, the handlers are triggered.
6. The expiring flow has been refactored to the following steps:
   6.1. First, when a data TTL expires, the expired event is fired, triggering the onExpired handlers
   6.2. Second, the data gets removed from the store firing the removed event and triggering the onRemoved handlers
   6.2.1. Important: the data is only removed after checking for data.isExpired(). I.e., if the data is manually refreshed in the onExpired handler, it won't be automatically removed from the store.
7. The Store.REMOVE_ON_EXPIRED_DISABLED customization was created to allow disabling the behavior of automatically removing expired data from the store. If we want to use it, just call save(Store.REMOVE_ON_EXPIRED_DISABLED, true) on the store (either a Session, a Service, or a Request).

*The Data object is a wrapper around the key/value records that are saved in the Store. Besides the key and the value, it contains relevant metadata such as createdAt, refreshedAt, ttl and isExpired.

Related Javadocs:

• Store
• Store.Data
• Store.Event
• Store.Handler

Requestor 1.2.0

This new release adds important improvements to the Store.

Now, we can set a TTL (time-to-live) long when saving data into the store. It represents how long the data is going to be valid. After this period, the data expires and gets removed from the store.

Also, now there are some Store Events that allow us to react when modifications happen to a key.

The existing store events are:

• Saved Event - it's fired when a new data is saved into the store.
  • It provides us access to the newData that's being saved and also the oldData that was in the key's slot before (null if there was none).
  • We can listen to this event by registering a handler with the onSaved method.
• Removed Event - it's fired when a data is removed from the store.
  • It provides us access to the oldData that's being removed.
  • We can listen to this event by registering a handler with the onRemoved method.
• Expired Event - it's fired when a data TTL expires.
  • It provides us access to the oldData that has expired.
  • We can listen to this event by registering a handler with the onExpired method.

In order to listen to any of these events, we need to bind a Store.Handler to a key, like in session.onSaved( "aKey", event -> {} ).

The Store.Handler is a functional interface that receives a Store.Event as the argument. This event object allows us to access both the old data that's being removed/replaced/expired (with event.getOldData()) and the new data that's being saved (with event.getNewData()).

The Store.Data is an object that holds:

• the value that was saved into the store,
• the key it was bound to,
• the ttl that was set for it (default 0) and
• the createdAt time that it was saved.

Additionally, the Store.Handler provides a cancel() method that we can call to deregister (unsubscribe) the handler from the store.

The Store Events now empower a complete communication-centric approach to building client apps. The basic idea behind it is to share one Session object among all UI components (graphical or not), and use this session to make requests and cache data that must be accessible to everyone. Each UI component can register handlers to listen when data is made available (or unavailable) in the session. We can even break down our session into lower-scope Service objects. People find it useful when they want to follow a subject-oriented design.

Remember Sessions, Services, and Requests have embedded Stores (they wrap their own stores and expose the Store methods). Still, all stores intercommunicate together in a tree structure. Check the Store documentation for more info about it.

Requestor 1.1.0

Requestor now offers full support for both JVM/Android 8+ and GWT 2.7+ platforms, compatible with the latest versions of them all.

The JVM/Android support is offered by the requestor-javanet impl. It is prepared to leverage the power of the upcoming Java Virtual Threads.

Important refactorings were made and many great features were implemented, highlighting:

• Await (JVM/Android only)
• Futures (JVM/Android only)
• Auto Json serialization for JVM/Android powered by the GSon lib with requestor-gson ext
• RetryPolice
• Chunking (HTTP Streaming)
• Gzip compression
• Skip request option
• AsyncRunner
• RequestLogger

v1.1.0-rc3

gzip compression

v1.1.0-rc2

jdk17 and gwt2.10 compatibility

v1.1.0-rc1

new requestor-javanet impl for jre/android

v1.0.0

Requestor is a session-based process-oriented stateful event-driven HTTP Client API that grounds communication-centric apps.

v1.0.0-rc2

Second release candidate for v1