This section contains description of general errors.
We use the following levels of estimated error severity:
...
| Info |
|---|
Levels of estimated error severity. If an error is present in the context of an API (or endpoint), it applies only to that API (or endpoint). |
| This severity level implies that the process |
...
Major: This is a significant flaw that causes the system to fail. However, certain parts of the system remain functional.
...
always/usually works badly. |
| This severity level implies that the process works badly in some cases. |
| This flaw results in unfavorable behavior but the system remains functioning. |
...
| This type of flaw won’t cause any major breakdown in the system. |
...
| Panel |
|---|
| panelIconId | 203c |
|---|
| panelIcon | :bangbang: |
|---|
| panelIconText | ‼️ |
|---|
| bgColor | #FFEBE6 |
|---|
|
List of identified issues in this category (click on the title to show details) |
| Expand |
|---|
| title | GEN-001: Allowing users to enter incorrect data |
|---|
|
Description | 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). |
|---|
Estimated severity |
|---|
|
...
| |
|---|
Examples | |
|---|
Suggested action | Enforceabsolutecompliance with the specification |
|---|
How communicated | Monitoring system Problem occurred for at least 15 providers in PROD (link1, link2) |
|---|
|
| Expand |
|---|
| title | GEN-002: Missing required fields |
|---|
|
|
| Expand |
|---|
| title | GEN-003: Attaching request body in error-response |
|---|
|
|
...
...
...
| |
|---|
Examples | |
|---|
Suggested action | A |
|---|
|
...
server should stop doing this, because it might result in leaking private data when such errors are reported |
|
...
| Expand |
|---|
| title | GEN-004: Attaching stack trace in error-response |
|---|
|
|
...
| A server attaches full stack traces of errors in error-responses. |
|---|
Estimated severity | |
|---|
Examples | |
|---|
Suggested action | A server should stop doing this, because full stack traces aren't helpful to other partners and are only making reports |
|---|
|
...
...
Estimated severity
...
Low
...
Examples
...
...
Suggested action
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. | How communicated | Monitoring system Problem occurred for at least 2 providers in PROD (link1, link2). |
|---|
|
| Expand |
|---|
| title | GEN-005: Wrong answer to a CNR or GET as part of CNR |
|---|
|
Description | According to specification “Once you receive a change notification, you respond with HTTP 200, and add the received identifiers to a queue. Later on, in the background, you will attempt to update your locally stored information on the received entities (e.g. by calling the get endpoints of the APIs which describe this entity). You SHOULD NOT try to refresh your data before sending your CNR API response. Refreshing the data (e.g. calling the get endpoint) is a separate operation, and the result of this operation MUST NOT influence the HTTP response of your CNR API” A number of partner send some error codes instead. |
|---|
Estimated severity | |
|---|
Examples | |
|---|
Suggested action | Enforceabsolutecompliance with the specification |
|---|
How communicated | Email correspondence with providers, testing sessions, GitHub This error was encountered in a number of mobility systems |
|---|
|