HTTP Durum Kodları - 4XX CLIENT ERROR Kodları

Giriş

Http Durum Kodları yazısına bakabilirsiniz.

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

Açıklaması şöyle

RFC 7807 has proposed “Problem Details for HTTP APIs” with the consideration of communicating non 2xx errors effectively (and in a standard way)

Bu belge şöyle

"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."

Çıktısı şöyle

{
  "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 Basic Authentication

- HTTP Digest Authentication
- OAuth2

gibi bir doğrulama/yetkilendirmek yöntemini kullanmak gerekir.

402 Payment Required

Örnek ver

403  Forbidden - Doğrulama/Yetkilendirme Problemi
Açı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 Saklanabilir
Bulunamayan 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

Bir örnek şöyle

... to indicate invalid Accept-Language request header value

407  Proxy Authentication Required
Açı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 Conflict
Açı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

413 Request Entity Too Large
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.