Change resource/remote function to method in BBEs

examples/client-class/client_class.bal

@@ -27,7 +27,7 @@ public client class Client {
 public function main() returns error? {
  Client albumClient = check new ("localhost:9090");
 
- // `->` is used to access the resource/remote functions in the client class.
+ // `->` is used to access the resource/remote methods in the client class.
  // Sends a `GET` request to the `/albums` resource.
  Album[] albums = check albumClient->/["albums"];
  io:println(albums);

examples/grpc-service-headers/grpc_simple_with_headers.md

@@ -1,6 +1,6 @@
 # gRPC service - Send/Receive headers
 
-The `grpc:Service` allows receiving headers and sending headers from/to a gRPC server. The gRPC - Protobuf CLI tool generates a `Context` record for each Protobuf message type, which contains the Protobuf message and the header map. The header map supports `string`and `string[]` types. The `Context` type of the required record is provided as the target type of the remote function to receive the headers. A `Context` record value is created with the required headers and is returned to the client. The `getHeader` and `getHeaders` methods are also available to manipulate the header values.
+The `grpc:Service` allows receiving headers and sending headers from/to a gRPC server. The gRPC - Protobuf CLI tool generates a `Context` record for each Protobuf message type, which contains the Protobuf message and the header map. The header map supports `string`and `string[]` types. The `Context` type of the required record is provided as the target type of the remote method to receive the headers. A `Context` record value is created with the required headers and is returned to the client. The `getHeader` and `getHeaders` methods are also available to manipulate the header values.
 
  ::: code grpc_simple_with_headers_service.bal :::
 

examples/http-basic-rest-service/http_basic_rest_service.md

@@ -1,6 +1,6 @@
 # REST service - Basic
 
-Ballerina language has first-class abstractions for service and resource concepts in the form of `service` and `resource functions`. A resource function consists of an accessor and path. A service can have a collection of resource functions. These abstractions allow mapping REST concepts such as operations, resource paths and resource representations cleanly into your program. `http:Service` can be used to write RESTful services. A service is defined with a base path, the path common to all resource paths. Each resource function is defined with the required operation such as `get`, `put`, `post`, etc and the path. Similar to regular functions resource functions have input parameters and return types that are mapped to the HTTP request and response.
+Ballerina language has first-class abstractions for service and resource concepts in the form of `service` and `resource methods`. A resource method consists of an accessor and path. A service can have a collection of resource methods. These abstractions allow mapping REST concepts such as operations, resource paths and resource representations cleanly into your program. `http:Service` can be used to write RESTful services. A service is defined with a base path, the path common to all resource paths. Each resource method is defined with the required operation such as `get`, `put`, `post`, etc and the path. Similar to regular functions resource methods have input parameters and return types that are mapped to the HTTP request and response.
 
 ::: code http_basic_rest_service.bal :::
 

examples/http-caller/http_caller.md

@@ -1,6 +1,6 @@
 # HTTP service - Caller object
 
-The `http:Caller` represents the endpoint that initiated the call toward a service. It is used to send responses back to the caller. In addition, it also contains meta information such as remote/local addresses. When the `http:Caller` is defined, the resource function return type is constrained to `error?`. `http:Caller` is useful to handle scenarios such as sending status code `100 Continue` or doing some work after sending the response to the caller. In most cases, `http:Caller` is not required as returning from the resource function sends the response back to the caller.
+The `http:Caller` represents the endpoint that initiated the call toward a service. It is used to send responses back to the caller. In addition, it also contains meta information such as remote/local addresses. When the `http:Caller` is defined, the resource method return type is constrained to `error?`. `http:Caller` is useful to handle scenarios such as sending status code `100 Continue` or doing some work after sending the response to the caller. In most cases, `http:Caller` is not required as returning from the resource method sends the response back to the caller.
 
 ::: code http_caller.bal :::
 

examples/http-default-resource/http_default_resource.md

@@ -1,6 +1,6 @@
 # HTTP service - Default resource
 
-The default resource slightly varies from the usual resource function as it uses `rest parameters` as the `resource path` and the `default` identifier as the `resource accessor`. The `rest parameters` allow any of the URL paths to be matched, and it supports `string`, `int`, `float`, `boolean`, and `decimal` as types. The `default` identifier also allows any HTTP methods to be dispatched to the resource function. Use it when designing a REST API to handle proxy services or as a default location to get dispatched if none of the other resources are matched.
+The default resource slightly varies from the usual resource method as it uses `rest parameters` as the `resource path` and the `default` identifier as the `resource accessor`. The `rest parameters` allow any of the URL paths to be matched, and it supports `string`, `int`, `float`, `boolean`, and `decimal` as types. The `default` identifier also allows any HTTP methods to be dispatched to the resource method. Use it when designing a REST API to handle proxy services or as a default location to get dispatched if none of the other resources are matched.
 
 ::: code http_default_resource.bal :::
 

examples/http-error-handling/http_error_handling.bal

@@ -15,7 +15,7 @@ service class ResponseErrorInterceptor {
  *http:ResponseErrorInterceptor;
 
  // The error occurred in the request-response path can be accessed by the 
- // mandatory argument: `error`. The remote function can return a response,
+ // mandatory argument: `error`. The remote method can return a response,
  // which will overwrite the existing error response.
  remote function interceptResponseError(error err) returns http:BadRequest {
  // In this case, all the errors are sent as `400 BadRequest` responses with a customized

examples/http-interceptor-error-handling/http_interceptor_error_handling.bal

@@ -29,11 +29,11 @@ service class RequestInterceptor {
 
 // A `RequestErrorInterceptor` service class implementation. It allows intercepting
 // the error that occurred in the request path and handle it accordingly.
-// A `RequestErrorInterceptor` service class can have only one resource function.
+// A `RequestErrorInterceptor` service class can have only one resource method.
 service class RequestErrorInterceptor {
  *http:RequestErrorInterceptor;
 
- // The resource function inside a `RequestErrorInterceptor` is only allowed 
+ // The resource method inside a `RequestErrorInterceptor` is only allowed
  // to have the default method and path. The error occurred in the interceptor
  // execution can be accessed by the mandatory argument: `error`.
  resource function 'default [string... path](error err) returns http:BadRequest {

examples/http-request-interceptor/http_request_interceptor.bal

@@ -15,7 +15,7 @@ table<Album> key(title) albums = table [
 service class RequestInterceptor {
  *http:RequestInterceptor;
 
- // A default resource function, which will be executed for all the requests. 
+ // A default resource method, which will be executed for all the requests.
  // A `RequestContext` is used to share data between the interceptors.
  // An accessor and a path can also be specified. In that case, the interceptor will be
  // executed only for the requests, which match the accessor and path.

examples/http-response-interceptor/http_response_interceptor.bal

@@ -15,7 +15,7 @@ table<Album> key(title) albums = table [
 service class ResponseInterceptor {
  *http:ResponseInterceptor;
 
- // The `interceptResponse` remote function will be executed for all the
+ // The `interceptResponse` remote method will be executed for all the
  // responses. A `RequestContext` is used to share data between interceptors.
  remote function interceptResponse(http:RequestContext ctx,
  http:Response res) returns http:NextService|error? {

examples/http-send-different-status-codes-with-payload/http_send_different_status_codes_with_payload.metatags

@@ -1,2 +1,2 @@
-description: This example is on how to use the status code records with a payload in an HTTP resource function.
+description: This example is on how to use the status code records with a payload in an HTTP resource method.
 keywords: ballerina, ballerina by example, bbe, http resource, return types, statusCode records

examples/http-send-different-status-codes/http_send_different_status_codes.md

@@ -1,6 +1,6 @@
 # REST service - Send different status codes
 
-The subtypes of the `http:StatusCodeResponse` record type represent different HTTP status code responses. Returning them from the resource function results in the relevant HTTP status code response. To send a non-entity body response, use the relevant constant value declared in the `http` module. These constant values can be directly returned from the resource method by specifying the relevant return type in the resource function signature. Use this when different status code responses need to be sent without a body and headers.
+The subtypes of the `http:StatusCodeResponse` record type represent different HTTP status code responses. Returning them from the resource method results in the relevant HTTP status code response. To send a non-entity body response, use the relevant constant value declared in the `http` module. These constant values can be directly returned from the resource method by specifying the relevant return type in the resource method signature. Use this when different status code responses need to be sent without a body and headers.
 
 ::: code http_send_different_status_codes.bal :::
 

examples/http-send-different-status-codes/http_send_different_status_codes.metatags

@@ -1,2 +1,2 @@
-description: This example is on how to use status code records in an HTTP resource function.
+description: This example is on how to use status code records in an HTTP resource method.
 keywords: ballerina, ballerina by example, bbe, http resource, return types, statusCode records

examples/http-service-jwt-authentication/http_service_jwt_authentication.md

@@ -1,6 +1,6 @@
 # HTTP service - JWT authentication
 
-The `http:Service` and resource function can be secured with JWT and additionally, scopes can be added to enforce authorization. It validates the JWT sent in the `Authorization` header against the provided configurations. Ballerina uses the concept of scopes for authorization. A resource declared in a service can be bound to one/more scope(s). The scope can be included in the JWT using a custom claim attribute. That custom claim attribute also can be configured as the `scopeKey`. In the authorization phase, the scopes of the service/resource are compared against the scope included in the JWT for at least one match between the two sets.
+The `http:Service` and resource method can be secured with JWT and additionally, scopes can be added to enforce authorization. It validates the JWT sent in the `Authorization` header against the provided configurations. Ballerina uses the concept of scopes for authorization. A resource declared in a service can be bound to one/more scope(s). The scope can be included in the JWT using a custom claim attribute. That custom claim attribute also can be configured as the `scopeKey`. In the authorization phase, the scopes of the service/resource are compared against the scope included in the JWT for at least one match between the two sets.
 
 ::: code http_service_jwt_authentication.bal :::
 

examples/http-service-oauth2/http_service_oauth2.md

@@ -1,6 +1,6 @@
 # HTTP service - OAuth2
 
-The `http:Service` and resource function can be secured with OAuth2 and additionally, scopes can be added to enforce fine-grained authorization. It validates the OAuth2 token sent in the `Authorization` header against the provided configurations. This calls the configured introspection endpoint to validate. Ballerina uses the concept of scopes for authorization. A resource declared in a service can be bound to one/more scope(s). The scope can be included in the introspection response using a custom claim attribute. That custom claim attribute also can be configured as the `scopeKey`. In the authorization phase, the scopes of the service/resource are compared against the scope included in the introspection response for at least one match between the two sets.
+The `http:Service` and resource method can be secured with OAuth2 and additionally, scopes can be added to enforce fine-grained authorization. It validates the OAuth2 token sent in the `Authorization` header against the provided configurations. This calls the configured introspection endpoint to validate. Ballerina uses the concept of scopes for authorization. A resource declared in a service can be bound to one/more scope(s). The scope can be included in the introspection response using a custom claim attribute. That custom claim attribute also can be configured as the `scopeKey`. In the authorization phase, the scopes of the service/resource are compared against the scope included in the introspection response for at least one match between the two sets.
 
 ::: code http_service_oauth2.bal :::
 

examples/websocket-basic-sample/websocket_basic_sample.bal

@@ -12,7 +12,7 @@ service /chat on new websocket:Listener(9090) {
 service class ChatService {
  *websocket:Service;
 
- // This `remote function` is triggered when a new message is received
+ // This `remote method` is triggered when a new message is received
  // from a client. It accepts `anydata` as the function argument. The received data 
  // will be converted to the data type stated as the function argument.
  remote function onMessage(websocket:Caller caller, string chatMessage) returns error? {

examples/websocket-service-jwt-auth/websocket_service_jwt_auth.md

@@ -1,6 +1,6 @@
 # WebSocket service - JWT authentication
 
-The `websocket:Service` and resource function can be secured with JWT and additionally, scopes can be added to enforce authorization. It validates the JWT sent in the `Authorization` header against the provided configurations. Ballerina uses the concept of scopes for authorization. The scope can be included in the JWT using a custom claim attribute. That custom claim attribute also can be configured as the `scopeKey`. In the authorization phase, the scopes of the service/resource are compared against the scope included in the JWT for at least one match between the two sets.
+The `websocket:Service` and resource method can be secured with JWT and additionally, scopes can be added to enforce authorization. It validates the JWT sent in the `Authorization` header against the provided configurations. Ballerina uses the concept of scopes for authorization. The scope can be included in the JWT using a custom claim attribute. That custom claim attribute also can be configured as the `scopeKey`. In the authorization phase, the scopes of the service/resource are compared against the scope included in the JWT for at least one match between the two sets.
 
 ::: code websocket_service_jwt_auth.bal :::
 

examples/websocket-service-oauth2/websocket_service_oauth2.md

@@ -1,6 +1,6 @@
 # WebSocket service - OAuth2
 
-The `websocket:Service` and resource function can be secured with OAuth2 and additionally, scopes can be added to enforce fine-grained authorization. It validates the OAuth2 token sent in the `Authorization` header against the provided configurations. This calls the configured introspection endpoint to validate. Ballerina uses the concept of scopes for authorization. The scope can be included in the introspection response using a custom claim attribute. That custom claim attribute also can be configured as the `scopeKey`. In the authorization phase, the scopes of the service/resource are compared against the scope included in the introspection response for at least one match between the two sets.
+The `websocket:Service` and resource method can be secured with OAuth2 and additionally, scopes can be added to enforce fine-grained authorization. It validates the OAuth2 token sent in the `Authorization` header against the provided configurations. This calls the configured introspection endpoint to validate. Ballerina uses the concept of scopes for authorization. The scope can be included in the introspection response using a custom claim attribute. That custom claim attribute also can be configured as the `scopeKey`. In the authorization phase, the scopes of the service/resource are compared against the scope included in the introspection response for at least one match between the two sets.
 
 ::: code websocket_service_oauth2.bal :::
 

examples/websub-webhook-sample/websub_webhook_sample.bal

@@ -16,7 +16,7 @@ import ballerina/websub;
  }
 }
 service on new websub:Listener(9090) {
- // Defines the remote function that accepts the event notification request for the WebHook.
+ // Defines the remote method that accepts the event notification request for the WebHook.
  remote function onEventNotification(websub:ContentDistributionMessage event) returns error? {
  json retrievedContent = check event.content.ensureType();
  if retrievedContent.zen is string {