Add native fetch client section for remote service consumption

[schwma]

No description provided.

[renejeglinsky]

Suggested change

	As an alternative to SAP Cloud SDK, CAP can use Node.js's built-in `fetch` API for remote service calls. Native fetch is selected per request based on the following rules, in that order:
	As an alternative to SAP Cloud SDK, CAP can use Node.js's built-in `fetch` API for remote service calls. Native fetch is selected per request based on the following rules:

[renejeglinsky]

Suggested change

	1. If the destination requires features only available in CloudSDK (e.g., BTP Destination Service resolution or non-basic authentication), CloudSDK is always used.
	1. If the destination requires features only available in SAP Cloud SDK (for example, SAP BTP Destination service resolution or non-basic authentication), the SAP Cloud SDK is always used.

[renejeglinsky]

Suggested change

	The native fetch client does not yet support named destinations via BTP Destination Service, only [application defined destinations](../services/consuming-services#use-application-defined-destinations). Authentication is limited to `NoAuthentication` and `BasicAuthentication`. CSRF token handling is not yet fully on par with SAP Cloud SDK.
	The native fetch client does not yet support named destinations using the SAP BTP Destination service. Only [application defined destinations](../services/consuming-services#use-application-defined-destinations) are supported. In addition, authentication is limited to `NoAuthentication` and `BasicAuthentication`. CSRF token handling is not yet at parity with SAP Cloud SDK.

[danjoa]

This reads as if we had already released FetchAPI for productive use, but I think that's not the case yet, is it? → Let's discuss that in our syncs for cds10

[schwma]

This reads as if we had already released FetchAPI for productive use, but I think that's not the case yet, is it? → Let's discuss that in our syncs for cds10

It could be used in a productive use case if the named destinations does not need to be looked up via BTP Destination Service and the authentication type is NoAuthentication or BasicAuthentication. Though this is highly unlikely to be the case in a production scenario.

[danjoa]

This reads as if we had already released FetchAPI for productive use, but I think that's not the case yet, is it? → Let's discuss that in our syncs for cds10

It could be used in a productive use case if the named destinations does not need to be looked up via BTP Destination Service and the authentication type is NoAuthentication or BasicAuthentication. Though this is highly unlikely to be the case in a production scenario.

No, we should keep the messages plain and simple:

• Projects don't need Cloud SDK during development anymore (but can opt-in to use it)
• But for production we still use Cloud SDK for now → e.g. to support destinations, etc.