which is the better option for implementing API’s
pub.client:http or pub.client:restClient
does RAD usage have any disadvantages? Can we directly configure host in RAD in IS admin page?
“Better” is usually a subjective evaluation. What works great in one scenario for someone, might be completely unacceptable to someone else.
According to recent documentation, pub.client:restClient is not intended for us to use/call directly. It is used by IS when generating services from a Swagger/OpenAPI spec.
For the RAD question, I personally avoid RAD whenever possible. Almost always gets in the way because it tries to be strict. For some, that’s a plus. For me, that has been a minus. (Hence my comment about “better” 
)
We tend to create relatively generalized “helpers” that use pub.client:http.
That works for us. But RAD may be preferable for your situation.
You’re not saying which type of APIs you want to implement, so I assume you want to implement some sort of REST APIs.
If you’re doing contract first REST APIs and you have OpenAPI v3 or Swagger 2 specifications, then you should RAD to ensure your implementation is compliant with these specifications. RAD generates flow service definitions and document types that matches these specifications. Document types also embed JSON constraints that you can use to validate API requests.
If you’re doing code first APIs, you’ve got more freedom. pub.client:http with a set of helpers can work. The benefit of RAD here would be the generation of the OpenAPI v3 or Swagger 2 specification based on the flow services signatures.
2 Likes
I have to agree on this. Also, for me some behavior seemed unexplainable and I couldn’t find sufficient documentation for those cases. In total there were some benefits, but they were outweighed by the challenges I faced. So I went for the HTTP client as well.