- Returing all resources matching criteria upon creation of a subscription
- Current situation is that the client is supposed to know the full state up front. If any change occurs between the client trying to figure out what the full state is and creating the subscription, that state change is lost. This is fixed by letting the server evaluate the criteria once the subscription is created - and then acting upon it.
- Resources leaving the criteria
- When resources leaves the criteria the client is not notified. This makes it pretty hard to base an implementation around a more event based approach where the server is supposed to notify the client about any changes that may occur. As long as resources leaving the criteria set is not part of the notifications clients will become stale pretty quickly.
- Order and use of ETag for updates
- The order of the updates is not described. If ETags are used by the notifying server, the client is able to detect if an update has gone missing one way or another. The use of order is currently not described when using Subscriptions. A global order might even be necessary pr. subscription if the client must be able to actually keep track of updates.
- Responses from the client
- Should a subscription automatically be marked as inactive when it starts issuing 4xx errors? Should a server retry on all 5xx errors? Should it be part of the spec? Currently it is very open i terms of interpretation.
- Web sockets lacks support for including payload
- The current description of web sockets does not mention the use of payloads. Is that intentional? Should it be mentioned as an option?
- REST hooks are not great in firewall'ed environments
- The REST hook design is far from optional in a firewalled environment. But that might just be a known issue.
FHIR Subscription resource 'stuff-worth-talking-about'