Giriş
Hata kodları belli bir yere kadar kullanışlı ancak REST çağrılarında hatanın sebebini tam olarak anlamak için yeterli değil. Açıklaması
şöyle.
One area of RESTful web API design that's quite frequently overlooked is how to report errors and problems, either related to the business or application. The proper usage of the HTTP status codes comes to mind first, and although quite handy, it is often not informative enough. Let us take 400 Bad Request as an example. Yes, it clearly states that the request is problematic, but what exactly is wrong?
1. Cacheable Durumu
Açıklaması şöyle
All 4xx status codes are by default not cacheable, except for 404, 405, 410 and 414, which are cacheable. We presume that editors of the spec did this with the best intentions, but the number of people who knows this nuance is probably quite close to the number of the spec editors. As a result, there are lots of cases (the author of this book had to deal with one) when 404 was returned erroneously and cached on clients, thus prolonging the outage for an indefinite time.
2. Problem Details for HTTP APIs
RFC 7807 has proposed “Problem Details for HTTP APIs” with the consideration of communicating non 2xx errors effectively (and in a standard way)
"This document defines a "problem detail" as a way to carry machine-readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs."
{
"type": "about:blank",
"title": "Invalid name passed",
"status": 400,
"detail": "Name should have only Alphabets",
"instance": "/greeting"
} İstemci MediaType.APPLICATION_PROBLEM_JSON ile bu RFC'yi kabul edeceğini belirtir
3. Hata Kodları
Burada çok kullanılan hata kodları için açıklamalar var
400 Bad Request
Açıklaması
şöyle.
Your browser sent a request that this server could not understand.
Açıklaması
şöyle. Hangi parametrenin yanlış olduğunu
standart olarak dönmenin yolu yok
... when some parameters are invalid or missing. This error makes absolutely no sense to clients unless specific missing or invalid field is specified — but that's exactly the thing the standard does nothing with! There are no conventional standards to specify which parameter is wrong exactly. Yes, we can, of course, invent a standard of ourselves, but that would contradict the REST idea of protocol transparency.
NB: some purists insist, that a 400 code indicates a problem with the request itself, i.e. malformed URI, or header, or body, etc. Sometimes 422 Unprocessable Entity or 412 Precondition Failed are claimed to be the ‘right’ code for invalid parameters error. It doesn't change anything, of course.
401 Not Authorized - Belirtilen Yetkilendirme Yöntemini Kullanarak Tekrar Gel
Sunucu bu cevabı gönderirse erişilmek istenen kaynağa yetkimiz olmadığını belirtir.
- HTTP Digest Authentication
- OAuth2
gibi bir doğrulama/yetkilendirmek yöntemini kullanmak gerekir.
402 Payment Required
Örnek ver
403 Forbidden - Doğrulama/Yetkilendirme ProblemiAçıklaması
şöyle. Doğrulama/Yetkilendirme problemi olunca sunucu bu değeri
dönebilir.
the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any). [..] However, a request might be forbidden for reasons unrelated to the credentials.
Çok fazla doğrulama/yetkilendirme yöntemi var. Bunlardan bazıları
şöyle
403 Forbidden when some authorization or authentication error occurs. There are several quite different Forbidden situations, which require quite different actions from the client:
— an authorization token is missing — the user must be invited to log in;
— the token is expired — the token refreshing procedure must be conducted;
— the token belongs to other user — usually indicates that some caches are stall;
— the token is revoked — usually a result of user logging out on all devices;
— the user is bruteforcing the authorization endpoint — some antifraud action is required;
— etc.
Each 403 reason indicates quite different scenarios, some of them (bruteforcing) have nothing in common with others.
404 Not Found - Dikkat Önbellekte SaklanabilirBulunamayan sayfalar için bu hata kodu döndürülüyor.
405 Method Not Allowed - Dikkat Önbellekte Saklanabilir
Açıklaması şöyle. Yani POST adresine GET gönderirsem bu cevabı alırım
405 Method Not Allowed means that the HTTP method is simply not supported. For example, a client might do a POST request on a resource where POST is not implemented or it’s meaningless.
A server generating the 405 response must also tell the client which HTTP methods it can do, using the Allow header.
406 Unacceptable
Sunucu, istemci tarafından gönderilen Accept alanlarına uyan bir cevap üretemiyor. Bunların dışında bir cevap üretebiliyor.
Örnek
... to indicate invalid Accept-Language request header value
407 Proxy Authentication RequiredAçıklaması
şöyle.
In case of a 407 error, the response that you are receiving must contain a special Proxy-Authenticate header. This header will tell you what kind of authentication the proxy server is expecting.
What you need to do is include a Proxy-Authorization header in your request. The typical syntax for a Proxy-Authorization header is Proxy-Authorization:<type-of-authentication-scheme> <credentials-for-authentication-at-proxy-server>.
Proxy-Authenticate header will let you know the type of authentication scheme that you need to use.
408 Request Timeout
Örnek ver
409 ConflictAçıklaması
şöyle.
The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.
Sistemin mevcut durumu istek ile çelişiyorsa gönderilir. Çıktı olarak şunu
alırız.
409 Conflict
your proposed change has been declined because ${REASON}.
The following resolution protocols are available: ${LINKS[@]})
Örnek
Optimistic Locking kullanıyorsak ve version numarası eski olan bir satırı güncellemek istersek şöyle
yaparız return ResponseEntity.status(HttpStatus.CONFLICT).body(exception.getMessage());
410 Gone - Dikkat Önbellekte Saklanabilir
Açıklaması
şöyle. 404'te sunucu adresi bilmiyor, 410 kodunda 404'ten farklı olarak sunucu adresin kalıcı olarak yok olduğunu biliyor
A 410 Gone error occurs when a user tries to access an asset which no longer exists on the requested server. In order for a request to return a 410 Gone status, the resource must also have no forwarding address and be considered to be gone permanently. This is the key differentiator from a 404 Not Found in that with a 404 error, the server does not know if the resource may be available again in the future.
411 Length Required
Örnek ver
412 Precondition Failed
Örnek ver
Sunucudan çok fazla veri istenirse
kullanılabilir. Örneğin 50 bin satır birden istenirse bu hata kodu döndürülebilir.
414 URI Too Long - Dikkat Önbellekte Saklanabilir
Örnek ver
415 Unsupported Media Type
Konu ile ilgili örnek lazım
416 Requested Range Not Satisfiable
Örnek ver
417 Expectation Failed
Örnek ver
429 Too Many Requests
Eğer sunucundaki bellek yetersizse, istekleri yerine getiremez. Bu durumda bu hatayı
dönebilir.
