Add best practices section for rule 108 (zalando#799)

* Add best practices section for rule 108

Re: zalando#792

* feat: accept best practice improvement (zalando#799)

Co-authored-by: Thomas Frauenstein <thomas.frauenstein@zalando.de>

* feat: accept improvement (zalando#799)

Co-authored-by: Thomas Frauenstein <thomas.frauenstein@zalando.de>

* feat: accept improvement (zalando#799)

Co-authored-by: Thomas Frauenstein <thomas.frauenstein@zalando.de>

---------

Co-authored-by: Tronje Krop <tronje.krop@zalando.de>
Co-authored-by: Thomas Frauenstein <thomas.frauenstein@zalando.de>

chapters/best-practices.adoc

@@ -322,3 +322,25 @@ later than the given date:
 === Conclusion
 We suggest to either use the _{ETag} in result entities_ or _{Last-Modified}
 / {If-Unmodified-Since}_ approach.
+
+
+[[handling-compatible-extensions]]
+== Handling compatible API extensions
+
+[[client-handling-compatible-extensions]]
+=== In the clients
+
+Client must not eliminate unknown optional fields from the 
+fetched resource payload, and to serialize them later when submitting the
+complete resource payload back to the API server via {PUT} (<<108>>).
+
+When using Java with Jackson serialization, for example, that can be achieved
+by including a field in the Java class representing the API resource, like the
+following one:
+
+[source,java]
+----
+@JsonAnyGetter
+@JsonAnySetter
+private Map<String, JsonNode> additionalProperties = new HashMap<>();
+----

chapters/compatibility.adoc

@@ -133,6 +133,7 @@ Service clients should apply the robustness principle:
 ** Follow the redirect when the server returns HTTP status code {301} (Moved
   Permanently).
 
+The <<handling-compatible-extensions>> section describes a best practice to implement the requirements in Java. 
 
 [#111]
 == {MUST} treat OpenAPI specification as open for extension by default

chapters/http-requests.adoc

@@ -193,6 +193,9 @@ suggest to choose one and only one of the following patterns per endpoint
 
 1. Use {PUT} with complete objects to update a resource as long as feasible
    (i.e. do not use {PATCH} at all).
+   *Note:* this choice by the API server imposes additional requirements on
+   the client (<<108>>) which can be implemented e.g. in Java following the 
+   practice <<handling-compatible-extensions>>.
 2. Use {PATCH} with {RFC-7396}[JSON Merge Patch] standard, a
    specialized media type `application/merge-patch+json` for partial
    resource representation to update parts of resource objects.