[API] Expose complete field sets for all endpoints (e.g. Contract, Licenses)

[M4XGR0]

The High-Level REST API (v2.2.0) returns only a small, hardcoded subset of fields
for several endpoints. Fields that are fully stored in the database and visible in
the GLPI UI are silently omitted from API responses.

Two concrete examples we ran into:

Contract— missing fields include:
begin_date, duration, notice, periodicity, billing, renewal, num,
suppliers_id, budgets_id, max_links_allowed, alert

SoftwareLicense — missing fields include:
number, expire, softwares_id, softwareversions_id_buy,
softwareversions_id_use, buy_date, use_date, is_valid

This is likely not limited to these two types — other endpoints may have the
same issue.

Request: Please expose the complete field set for each endpoint, consistent with what the GLPI UI already provides.

Thanks for your amazing work on the project!

[farfromexact]

The missing fields are a good example of why the API should not rely on a small hand-maintained response allowlist for every resource. At the same time, exposing every database column blindly can bypass permissions or return implementation details that the UI never intended to publish.

A useful design would be a versioned resource field schema:

• each endpoint declares its supported public fields and their types
• permissions and entity visibility are applied before serialization
• clients can request an explicit field set when they need a smaller payload
• the default response is documented and stable across minor releases
• the API metadata or OpenAPI document lists the available fields

For Contract and SoftwareLicense, the examples should become regression fixtures, including null values, dates, relations, and permission-restricted fields. It is also worth checking whether some names are stored under relation IDs while the UI displays resolved labels; the API should expose both in a predictable way rather than changing the meaning of an existing field.

A complete field set would be valuable, but I would implement it through a shared resource schema and tests for all endpoints, not by copying the UI's current columns one controller at a time.

[cconard96]

The new API is still a work in progress but,

1. If scalar (a single string, number, etc value) or "dropdown" properties (where they can be represented by a single ID and name pair) are missing, please open a bug report (or a pull request).
2. Nothing is silently omitted really. If the property isn't in the API schema, then it doesn't exist. Unlike the legacy API, this new API is not just a thin wrapper around the DB/internal GLPI logic so properties are explicitly defined. This also helps to keep GLPI changes from breaking the version contract of the API.
3. Not all linked data is included in the REST endpoint responses because that is a huge amount of data that is probably not needed. For REST, this is supposed to be delegated to other endpoints (for example /Project/5/Task for a project's tasks). Otherwise, this is exactly the reason the new API offers a GraphQL endpoint; You can choose the data you need (including related data if the links are defined in the schema) and get exactly that data back.
4. The links for GraphQL are a little sparse at the moment but work has already been started to expand the graph. Until the linked PR, there was no way to define properties in schemas that only exist for GraphQL queries.
5. GLPI is really, really big. Currently the API contains over 300 schemas (soon to be over 350) with over 3500 top-level properties and over 1200 unique routes. That is a lot of work for one developer that also works on other parts of GLPI, especially when trying to ensure it remains a good UX, but I am constantly working on adding the missing fields and endpoints. There are some things that are currently blocked for one reason or another though.
6. The legacy API still exists and should be able to cover the missing functionality of the new API, even if it is far from ideal.