In LoopBack 3, it was very easy to get a fully-featured CRUD REST API with very little code: a datasource configuration for a 3rd party webservice (REST, SOAP, etc.) and an empty model attached to that datasource.
Let's provide the same simplicity to LB4 users too and build on top of the mechanism implemented for models in #2036.
- User creates a datasource using a web-service connector like REST or SOAP. (No change here.)
- User declaratively defines how to expose this service via REST API. At minimum, we need a model name or URL path where to mount the service API.
@loopback/boot processes this configuration and registers appropriate service proxies & controllers with the app.
Note: having config for multiple services in a single JSON file can quickly become a maintenance nightmare, see strongloop/loopback#1316. It will be better to have one config file per service, e.g. public-services/geocoder.json.
See also
In LoopBack 3, it was very easy to get a fully-featured CRUD REST API with very little code: a datasource configuration for a 3rd party webservice (REST, SOAP, etc.) and an empty model attached to that datasource.
Let's provide the same simplicity to LB4 users too and build on top of the mechanism implemented for models in #2036.
@loopback/bootprocesses this configuration and registers appropriate service proxies & controllers with the app.Note: having config for multiple services in a single JSON file can quickly become a maintenance nightmare, see strongloop/loopback#1316. It will be better to have one config file per service, e.g.
public-services/geocoder.json.See also