GitLab

Some enablers may have limits (according to vf_os-D3.1 text bellow). The request-handler should respect these limits or return error codes when surpassing them.

• Limits: To prevent abuse, all the enablers’ developers MAY add rate limiting to the communication interfaces. These limitations will be configured by the admin and MAY differ for all the enabler implementations. One of the limits to be configured is rate limits. These limits are specified both in human readable wild-card and in regular expressions and will indicate for each HTTP verb which will be the maximum number of operations per time unit that a user can request. After each unit time the counter is initialized again. If too many requests are received from a user within the stated period of the time, a response with status code 429 (meaning "Too Many Requests") should be returned. OR a 413 HTTP response can be returned with a Retry-After header to notify the client when they can attempt to try again. Limits can alternatively be provided as absolute limits. In this case, absolute values are specified, e.g. maximum total amount of RAM (MB). Additionally all the communication interfaces must provide mechanism for determining limits programmatically. Applications can use the GET verb with the /limits URI in order to retrieve this information. This operation must return Normal response code(s), e.g. 200 or 203 and will have to manage some possible errors like compute fault, service unavailable, unauthorized operation, forbidden, bad request, bad method or operation over limit.