spring-cloud
Extend semantics of HTTP endpoints
When trying to write actual application code, I'm finding the simple mapping from Function, Supplier and Consumer to HTTP/REST actions a bit limiting. Some ideas...
-
[x] Tighten up the content negotiation, so that HTTP clients know what to expect. E.g. actually test what happens when you POST to a
Consumer. -
[x] Make it easy to express the common idiom "POST an entity" get back a 202 (Accepted), or a 201 (Created) or 204 (No Content)?
-
[ ] Make it possible for the developer to control these patterns.
-
[ ] Maybe allow users to "replay" content that was streamed into a
Consumer(automatically generate a GET endpoint that mirrors a POST for instance). -
[ ] More nuanced handling of infinite streams. Pagination as an alternative to SSEs, for instance.
-
[x] Allow resource paths to be configured more flexibly (e.g. by bean name and by alias as well). This could open up the possibility of having "/" resource separators in URI paths. Makes configuring a messaging stream more of a headache, but I guess that can be done with aliases.
-
[x] Make single-valued functions return single values (not arrays) if the request is single-valued
- [x] = done
Example where "/" separators would be useful: the Commander pattern. Commander has 2 groups of endpoints (/commands and /events).
-
/commands accepts POST and publishes the entities (after maybe some decoration) to a topic/Supplier. It also allows commands to be listed and viewed by id, e.g. at
GET /commands/{id}. -
/events accepts POST from consumers of the commands (each event is a reaction to a command or another event), and publishes the entities to a topic/Supplier. It also allows commands to be listed and viewed by id, e.g. at
GET /events/{id}.
You can implement the basic POST with 2 Functions called "commands" and "events", but the GET by ID and the "replay" endpoints cannot be implemented with "natural" URIs yet.