Web Services changes

There are changes in support of web services in Genero 6.00.

REST functions must include a RETURNS() clause

Starting from FGLGWS 6.00.01, all REST functions must declare a RETURNS() clause, even when the function does not return a value. This enforces consistent function signatures and prevents ambiguous web service definitions.

Action needed:

  • You must add a RETURNS() clause to every REST function declaration.

  • Update your existing REST functions to include a RETURNS() declaration — either an explicit return type or an empty RETURNS().

Omitting the RETURNS clause will raise error -9158

For example:

Before (no return): 
FUNCTION notifyUser(userId INTEGER)
    ATTRIBUTE(WSPost)
   # ...
END FUNCTION
Before (returns data):
FUNCTION notifyUser(userId INTEGER)
    ATTRIBUTE(WSPost)
  # ...
  RETURN "data"
END FUNCTION
Now (no return value — explicit empty RETURNS() must be added):
FUNCTION notifyUser(userId INTEGER)
    ATTRIBUTE(WSPost)
# The web service function 'notifyUser' requires a RETURNS() clause.
# See error number -9158.
END FUNCTION
Now (returns data — explicit RETURNS(return-type) must be added):
FUNCTION notifyUser(userId INTEGER)
    ATTRIBUTE(WSPost)
# The web service function 'notifyUser' requires a RETURNS() clause.
# See error number -9158.
  RETURN "data"
END FUNCTION
For more information about using RETURN clauses in RESTful functions, go to Return value attributes

JSONEnum: separator changed from pipe to comma

Starting from FGLGWS 6.00.01, the JSONEnum attribute uses commas instead of pipes to separate values in its list (for example, "pending","approved","rejected"). Update declarations that use the old pipe format to the new comma-separated format to avoid validation errors.

An invalid separator will raise error -9159

Example:

Before:

TYPE ok_string STRING  ATTRIBUTE(JSONEnum = `"pending"|"approved"|"rejected"`)

Now:

TYPE ok_string STRING  ATTRIBUTE(JSONEnum = `"pending","approved","rejected"`)

For more details, go to JSONEnum

Implicit type conversions in json.Serializer have been removed

Starting from FGLGWS 6.00.00, implicit type conversions in json.Serializer have been removed.

For example, previously you could deserialize a JSON string like "true" to a FGL BOOLEAN (1), or "123" to a FGL INTEGER (123).

Now, these assignments will result in errors unless explicitly authorized.

  • If your application relied on automatic type conversions during JSON serialization/deserialization with json.Serializer, you must now handle these conversions explicitly or use util.json if you require the old behavior.

  • The allowImplicitConversion setting does not restore the previous implicit conversion behavior in json.Serializer.

Ensure that JSON payloads sent to your 4GL applications use the correct types, as mismatches will now result in errors rather than silent conversions.

For more details, go to Primitive type serialization.

Change in allowImplicitConversion behavior

The handling of implicit conversions for BDL types has also changed. Previously, primitive types were always allowed to convert implicitly, regardless of the allowImplicitConversion setting. Now, implicit conversions for all BDL types, including primitive types, are controlled by this option. If it is not set to 1, implicit conversions are no longer permitted.

For more details about the json.Serializer allowImplicitConversion option, go to allowImplicitConversion.

Changes in earlier versions

Make sure to check the upgrade notes of earlier versions, to not miss changes introduced in maintenance releases. For more details, see Web services changes in BDL 5.01.

Notable changes introduced in maintenance releases: