Temporal child workflows can have multiple usages, see more info here.
For the mentioned use case, yes you can have your child workflow hosted by a separate service, and have its own set of workers. Your child workflow (and its workers) and be written in a separate programming language as well for which Temporal has SDKs for. (see polyglot examples here and here).
You do not need to wrap the parent/child communication via some rest apis at all. If both services communicate with the same Temporal service you can use the out of box gRPC communication without issues. Parent workflow in service A and the child workflow in service B can run on different task queues.
They could even run on different namespaces, but at this time would not advice this as there are still couple of issues with cross-namespace invocations that need to be fixed on the server side before we can start recommending this use case.
So looking at child-workflow sample, In your parent workflow you could specify ChildWorkflowOptions->TaskQueue, for example:
cwo := workflow.ChildWorkflowOptions{
WorkflowID: "MyChildWorkflowId",
TaskQueue: "childWfTaskQueue",
// ...
}
Your parent workflow can invoke the child on a different task queue via its workflow type (by default the name of the workflow function) so you do not have to your code between these services, in the child-workflow example:
err := workflow.ExecuteChildWorkflow(ctx, "SampleChildWorkflow", "World").Get(ctx, &result)
Overall you can think of activity and child workflow invocations as remote procedure calls, and task queue names being endpoints. Hope this helps.