0

I have 3 restful services (ServiceA, ServiceB and ServiceC) that handle 2 resources (ResourceA and ResourceB). The media type of the resources is application/hal+json.

  • ServiceA generates ResourceA;
  • ServiceB consumes ResourceA and produces ResourceB;
  • ServiceC coordinates the production of ResourceB by getting ResourceA from ServiceA and posting it to ServiceB.

I see basically two ways to organize this interaction.

  1. ServiceC as the ResourceA direct intermediator

    • ServiceC gets the full ResourceA from ServiceA
    • ServiceC post it to ServiceB
    • ServiceB returns ResourceB

  2. ServiceC as the ResourceA indirect intermediator

    • ServiceC gets only a link to ResourceA on ServiceA (through the Content Location header on ResourceA creation, for example)
    • ServiceC post this link on to ServiceB (using a link rel of the HAL media type)
    • ServiceB directly gets the full ResourceA from ServiceA
    • ServiceB returns ResourceB

The first approach seems to be the "classic" one while the second one would be cheaper since there is only one full transmission of ResourceA (ServiceA -> ServiceB) instead of two (ServiceA -> ServiceC -> ServiceB). Ideally, the second approach would be the better one for a big enough ResourceA.

Is there any problem in using the second approach? Is this considered a "anti-pattern" or is it not secure/recomendable in some way? Is there a better interaction pattern?

Rafael Regis
  • 65
  • 6

1 Answers1

0

You can use any approach. In second approach you need to be sure that ServiceA is accessible from ServiceB. If it is accessible, then actually I am not able to guess reason why we need altogether separate service i.e. ServiceC for co-ordination. ServiceB can directly subscribe to events in ServiceA. If you are planning to use some kind of polling then would suggest to have a look at http://resthooks.org/ which will reduce network calls as well as improve server performance.

Bhisham Balani
  • 228
  • 1
  • 4
  • I'm not sure if subscribing to a service is really that RESTful. It burdens some state to the service. If the service is very popular and some resource is updating, the server needs to notify each subscriber on the change which may reduce overall throughput - especially if resources change frequently. HTTP provides flexible caching mechanism and conditional GET requests which, if used correctly, may reduce the number of requests or processing time drastically. Of course this might not be possible in all situations. – Roman Vottner Jun 30 '15 at 08:18
  • But if resource is updating frequently then one needs to frequently poll the server frequently. One may use Batching in such a case, as described here: http://resthooks.org/docs/performance/ – Bhisham Balani Jun 30 '15 at 08:51
  • you assume that a client really wants to be informed on any change. Sometimes the client is just interested in the last state but not in the n states before. Via the server-push like system, the client is notified on every single update, while the push may skip these n updates in between. The "server-push" like architcture can also be realized using a callback URL the client is running a listening service at - though, this is not RESTful IMO as the client needs explicit knowledge of the service and the required callback. Plenty of HTTP clients will fail this requirement – Roman Vottner Jun 30 '15 at 09:42
  • If client is just interested in last state update then while subscribing this can be informed to server that in which updates client is interested in, so that server sends only desired updates. I agree, "server-push" will require callback and browser based http clients will fail this requirement, here the question was between services and with that respect is the reply. – Bhisham Balani Jul 01 '15 at 06:18