Page Comparison

If a specification requires some field to be in a specific format, applications should have proper server-side validation to prevent their users from entering incorrect data. Perfect examples are fields where the value is expected to be an email (like email in Mobility Factsheet API) or a URL (like website-url in Institutions API).

Enforceabsolutecompliance with the specification

Monitoring system

Problem occurred for at least 15 providers in PROD (link1, link2)

Fields specified as required (e.g. decision-weeks-limit in Mobility Factsheet API) must be provided in the API response. Such errors in many cases can be easily detected in your tests by validating your responses with the XSD schemas. You can also use validators available in the DEV Registry Service.

Enforceabsolutecompliance with the specification

Monitoring system

Problem occurred for at least 11 providers in PROD

A provider server attaches full request body and parameters in error-responses in the Stats Portal.

A provider server should stop doing this, because it might result in leaking private data when such errors are reported to the Stats Portalwith the Monitoring API.

Monitoring system

Problem occurred for at least 2 providers in PROD (link1, link2) and 1 other in DEV

A server attaches full stack traces of errors in error-responses. Full stack traces aren't helpful to other partners and are only making reports in the Stats Portal less readable.

A server should stop doing this, because full stack traces aren't helpful to other partners and are only making reports sent with the Monitoring API less readable. In case of unknown errors it is enough to return some generic message, e.g. "Something went wrong. Administrators have been notified. We'll try to fix it ASAP.", as suggested in the specification.

Monitoring system

Problem occurred for at least 2 providers in PROD (link1, link2).