Connect services and follow changes
A MAMS agent can consume another service through HTTP whether that service contains agents or conventional application code. Use ASTRA messages inside an application; use HTTP for resource contracts across service boundaries.
Make one request and check its result
Run the passive greeting collection from chapter 2 on port 9000. The HTTP client project runs separately on port 9001. It reads the collection, creates an item, changes it, deletes it and exits. The complete client walkthrough explains each step.
The client calls !setup(9001) for its infrastructure but does not create a base: using the HTTP client does not require exposing its own business resources. Start setup once per JVM; additional agents in that process join through !init() after setup completes.
Check the status before reading a successful result. A completed HTTP exchange can still return 404, 409 or another error. Transport failure is different: it fails the action, so use ASTRA recovery to decide what happens next.
Follow the returned resource identity
After POST, use Location to find the newly created child. The example client’s localhost rewrite is a local-development accommodation for server-generated host addresses, not general service discovery. Container and proxy deployments need an explicit public-address contract; see deployment addresses.
If a POST times out, its outcome may be unknown: the server could have created the resource before the client lost its response. Retrying with a different slug can create a second request. A fixed slug can reveal a conflict, but a 409 alone does not prove the existing resource represents the same business request. Decide how to correlate or deduplicate submissions before adding retries.
Poll a business result
The delivery service acknowledges request creation and then updates its state. A client should read the returned URI until it sees delivered or failed. Bound the overall wait, leave a delay between reads, and distinguish business failure from an unreachable service.
Client observation |
What it establishes |
|---|---|
POST returns |
A resource was created |
GET returns an intermediate state |
Work has been reported in progress |
GET returns |
The service reports business success |
GET returns |
The service reports business failure |
Transport timeout |
The client lacks a definitive result from that exchange |
Do not interpret disappearance of a resource or expiration of the client’s wait as successful completion.
Subscribe when polling is unsuitable
WebSub lets a publisher advertise a hub and a subscriber register a callback. The hub verifies the callback with a challenge, and the subscriber handles content through !topicUpdate(...). The callback is an HTTP resource, so its address must be reachable from the hub.
The WebSub example directly creates a custom topic artifact, initializes a hub and demonstrates an update. Publishing is explicit: call !publish(topic) at the point you intend to distribute the representation. Do not assume every resource replacement automatically broadcasts it.
The example uses a four-second timer to allow subscription startup. That is a demonstration timing assumption rather than confirmation that a subscription is ready. When integrating it into an application, establish readiness and decide how to handle missed updates, restarts and subscriber failures. A callback challenge verifies control of the endpoint; it does not establish trust in every later payload.
Try it
Run the greeting client after stopping the server and observe the transport failure. Then compare polling a delivery with the WebSub example: identify who initiates each HTTP exchange, where the callback lives, and when publication occurs.
Next: Build a cooperating service.