REST API 故障排除
- Tier: Free, Premium, Ultimate
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
使用 REST API 时,您可能会遇到问题。
要进行故障排除,请参考 REST API 状态码。包含 HTTP 响应头和退出码也可能会有帮助。
状态码
GitLab REST API 会根据上下文和操作在每次响应中返回一个状态码。请求返回的状态码在故障排除时很有用。
下表概述了 API 功能的一般行为方式。
| 请求类型 | 描述 |
|---|---|
GET |
访问一个或多个资源并以 JSON 格式返回结果。 |
POST |
如果资源成功创建,返回 201 Created,并以 JSON 格式返回新创建的资源。 |
GET / PUT / PATCH |
如果资源成功访问或修改,返回 200 OK。修改后的结果以 JSON 格式返回。 |
DELETE |
如果资源成功删除,返回 204 No Content;如果资源计划删除,返回 202 Accepted。 |
下表显示了 API 请求可能的返回码。
| 返回值 | 描述 |
|---|---|
200 OK |
GET、PUT、PATCH 或 DELETE 请求成功,资源本身以 JSON 格式返回。 |
201 Created |
POST 请求成功,资源以 JSON 格式返回。 |
202 Accepted |
GET、PUT 或 DELETE 请求成功,资源已安排处理。 |
204 No Content |
服务器已成功满足请求,响应负载正文中没有额外内容。 |
301 Moved Permanently |
资源已永久移动到 Location 头部给出的 URL。 |
304 Not Modified |
自上次请求以来,资源未被修改。 |
400 Bad Request |
API 请求的必需属性缺失。例如,未提供问题的标题。 |
401 Unauthorized |
用户未通过身份验证。需要有效的 用户 token。 |
403 Forbidden |
请求不被允许。例如,用户不允许删除项目。 |
404 Not Found |
无法访问资源。例如,找不到资源的 ID,或用户无权访问该资源。 |
405 Method Not Allowed |
请求不受支持。 |
409 Conflict |
已存在冲突的资源。 |
412 Precondition Failed |
请求被拒绝。如果在尝试删除资源时提供了 If-Unmodified-Since 头部,而该资源在此期间被修改,则可能发生此情况。 |
422 Unprocessable |
实体无法处理。 |
429 Too Many Requests |
用户超过了 应用程序速率限制。 |
500 Server Error |
处理请求时,服务器出现问题。 |
503 Service Unavailable |
服务器无法处理请求,因为服务器暂时过载。 |
状态码 400
使用 API 时,您可能会遇到验证错误,在这种情况下,API 会返回 HTTP 400 错误。
在以下情况下会出现此类错误:
- API 请求的必需属性缺失(例如,未提供问题的标题)。
- 属性未通过验证(例如,用户个人简介过长)。
当属性缺失时,您会收到类似以下内容的信息:
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"message":"400 (Bad request) \"title\" not given"
}当发生验证错误时,错误消息会有所不同。它们包含验证错误的所有详细信息:
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"message": {
"bio": [
"is too long (maximum is 255 characters)"
]
}
}这使得错误消息更易于机器读取。格式可以描述如下:
{
"message": {
"<property-name>": [
"<error-message>",
"<error-message>",
...
],
"<embed-entity>": {
"<property-name>": [
"<error-message>",
"<error-message>",
...
],
}
}
}包含 HTTP 响应头
HTTP 响应头在故障排除时可以提供额外信息。
要在响应中包含 HTTP 响应头,请使用 --include 选项:
curl --request GET \
--include \
--url "https://gitlab.example.com/api/v4/projects"
HTTP/2 200
...包含 HTTP 退出码
API 响应中的 HTTP 退出码在故障排除时可以提供额外信息。
要包含 HTTP 退出码,请包含 --fail 选项:
curl --request GET \
--fail \
--url "https://gitlab.example.com/api/v4/does-not-exist"
curl: (22) The requested URL returned error: 404被检测为垃圾邮件的请求
REST API 请求可能被检测为垃圾邮件。如果请求被检测为垃圾邮件且:
-
未配置 CAPTCHA 服务,将返回错误响应。例如:
{"message":{"error":"Your snippet has been recognized as spam and has been discarded."}} -
已配置 CAPTCHA 服务,您将收到包含以下内容的响应:
needs_captcha_response设置为true。- 设置了
spam_log_id和captcha_site_key字段。
例如:
{"needs_captcha_response":true,"spam_log_id":42,"captcha_site_key":"REDACTED","message":{"error":"Your snippet has been recognized as spam. Please, change the content or solve the reCAPTCHA to proceed."}}-
使用
captcha_site_key通过适当的 CAPTCHA API 获取 CAPTCHA 响应值。 仅支持 Google reCAPTCHA v2。 -
重新提交请求,并设置
X-GitLab-Captcha-Response和X-GitLab-Spam-Log-Id头部。export CAPTCHA_RESPONSE="<CAPTCHA response obtained from CAPTCHA service>" export SPAM_LOG_ID="<spam_log_id obtained from initial REST response>" curl --request POST \ --header "PRIVATE-TOKEN: $PRIVATE_TOKEN" \ --header "X-GitLab-Captcha-Response: $CAPTCHA_RESPONSE" \ --header "X-GitLab-Spam-Log-Id: $SPAM_LOG_ID" \ --url "https://gitlab.example.com/api/v4/snippets?title=Title&file_name=FileName&content=Content&visibility=public"
使用反向代理时出现 404 Not Found 错误
如果您的 GitLab 实例使用反向代理,在使用 GitLab 编辑器扩展、GitLab CLI 或包含 URL 编码参数的 API 调用时,您可能会看到 404 Not Found 错误。
当您的反向代理在将参数传递给 GitLab 之前解码 /、? 和 @ 等字符时,会出现此问题。
要解决此问题,请编辑反向代理的配置:
- 在
VirtualHost部分,添加AllowEncodedSlashes NoDecode。 - 在
Location部分,编辑ProxyPass并添加nocanon标志。
例如:
<VirtualHost *:443>
ServerName git.example.com
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/git.example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/git.example.com/privkey.pem
SSLVerifyClient None
ProxyRequests Off
ProxyPreserveHost On
AllowEncodedSlashes NoDecode
<Location />
ProxyPass http://127.0.0.1:8080/ nocanon
ProxyPassReverse http://127.0.0.1:8080/
Order deny,allow
Allow from all
</Location>
</VirtualHost>server {
listen 80;
server_name gitlab.example.com;
location / {
proxy_pass http://ip:port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_read_timeout 300;
proxy_connect_timeout 300;
}
}有关更多信息,请参阅 issue 18775。