RFC RCP-010: Acceptance Tests for Add/Edit

[darnjo]

Here is the initial set of BDD acceptance testing rules (Gherkin Reference) reviewed on the June 17, 2021 Certification Subgroup call:

Feature: Web API Server Add/Edit Endorsement
  The Add/Edit Endorsement contains tests for Create, Update, and Delete actions,
  which are MAY requirements at this time.
  # SEE: https://reso.atlassian.net/wiki/spaces/RESOWebAPIRCP/pages/2239399511/RCP+-+WEBAPI-010+Add+Functionality+to+Web+API+Specification

  ######################################################################################################################
  # >> Discuss ...
  # Selected Conformance Rules for Updatable Services
  #
  # To be considered an Updatable OData 4.0 Service, the service additionally:
  #   https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#sec_OData40MinimalConformanceLevel
  #
  #     18.  MUST include edit links (explicitly or implicitly) for all updatable or deletable resources according to [OData-JSON]
  #     19.  MUST support POST of new entities to insertable entity sets (section 11.4.1.5 and 11.4.2.1)
  #     20.  MUST support POST of new related entities to updatable navigation properties (section 11.4.2)
  #     21.  MUST support POST to $ref to add an existing entity to an updatable related collection (section 11.4.6.1)
  #
  #     22.  MUST support PUT to $ref to set an existing single updatable related entity (section 11.4.6.3)
  #     23.  MUST support PATCH to all edit URLs for updatable resources (section 11.4.3)
  #
  #     24.  MUST support DELETE to all edit URLs for deletable resources (section 11.4.5)
  #     25.  MUST support DELETE to $ref to remove a reference to an entity from an updatable navigation property (section 11.4.6.2)
  #
  #     26.  MUST support If-Match header in update/delete of any resources returned with an ETag (section 11.4.1.1)
  #     27.  MUST return a Location header with the edit URL or read URL of a created resource (section 11.4.2)
  #     28.  MUST include the OData-EntityId header in response to any create or upsert operation that returns 204 No Content (section 8.3.4)
  #     29.  MUST support Upserts (section 11.4.4)
  #
  #     30.  SHOULD support PUT and PATCH to an individual primitive (section 11.4.9.1) or complex (section 11.4.9.3) property (respectively)
  #     31.  SHOULD support DELETE to set an individual property to null (section 11.4.9.2)
  #     32.  SHOULD support deep inserts (section 11.4.2.2)
  #     33.  MAY support set-based updates (section 11.4.13) or deletes (section 11.4.14) to members of a collection
  #
  # In addition, to be considered an Updatable OData 4.01 Service, the service:
  #   https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#sec_OData401MinimalConformanceLevel
  #
  # 	18.  MUST conform to the OData 4.0 Minimal Conformance Level for an Updatable service.
  # 	19.  MUST support DELETE to the reference of a collection member to be removed, identified by key (section 11.4.6.2)
  #
  # 	20.  SHOULD support PUT against single entity with nested content
  # 	21.  SHOULD support deep updates (section 11.4.3.1) and deep inserts (section 11.4.2.2)
  # 	22.  SHOULD support PUT or DELETE to $ref of a collection-valued nav prop
  #
  #  	23.  MAY support POST to collections of complex/primitive types
  # 	24.  MAY support PATCH and DELETE to a collection
  # 	25.  MAY support POST, PATCH and DELETE to a collection URL terminating in a type cast segment
  # 	26.  MAY support PATCH to entity sets using the 4.01 delta payload format
  # 	27.  MAY support $select and $expand on data modification requests
  #
  ######################################################################################################################

  Background:
    Given a RESOScript file was provided
    And Client Settings and Parameters were read from the file
    And a test container was successfully created from the given RESOScript
    And the test container uses an authorization_code or client_credentials for authentication

  ######################################################################################################################
  # Create Record Succeeds
  ######################################################################################################################
  #   To create an entity in a collection, the client sends a POST request to that collection's URL.
  #
  #   The POST body MUST contain a single valid entity representation.
  #
  #   The entity representation MAY include references to existing entities as well as content for new related entities,
  #     but MUST NOT contain content for existing related entities.
  #
  #   The result of the operation is the entity with relationships to all included references to existing entities
  #     as well as all related entities created inline.
  #
  #   >> Should we test?
  #   If the key properties for an entity include key properties of a directly related entity, those related entities
  #     MUST be included either as references to existing entities or as content for new related entities.
  #
  #   >> Not tested here
  #   An entity may also be created as the result of an Upsert operation.
  #
  #   >> Should we support this here? This would mean that we'd check the fields against the metadata
  #   >> and then expect those items to be present in the re-query even if they weren't defined in the metadata...
  #   To create an open entity (an instance of an open type), additional property values beyond those specified in
  #     the metadata MAY be sent in the request body. The service MUST treat these as dynamic properties and add them
  #     to the created instance.
  #
  #   >> This was the initial assumption for testing?
  #   If the entity being created is not an open entity, additional property values beyond those specified in the
  #     metadata SHOULD NOT be sent in the request body. The service MUST fail if unable to persist all property
  #     values specified in the request.
  #
  #   >> Should we test that defined default values were honored for items not passed in the POST request?
  #   Properties with a defined default value, nullable properties, and collection-valued properties omitted from the
  #     request are set to the default value, null, or an empty collection, respectively.
  #
  #   >> Covered below
  #   Upon successful completion, the response MUST contain a Location header that contains the edit URL or read URL
  #     of the created entity.
  #
  #   >> Are we testing the 204 and supporting the return=minimal header? If so, that seems like a different test?
  #   Upon successful completion the service MUST respond with either 201 Created and a representation of the created
  #     entity, or 204 No Content if the request included a Prefer header with a value of return=minimal and did not
  #     include the system query options $select and $expand.
  #
  ###########
  #   >> Discuss - do we support links in this version? Not in original RCP-010 spec.
  #   Links to existing Entities:
  #     https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#sec_LinktoRelatedEntitiesWhenCreatinganE
  #
  #   >> Discuss - Do we support/test for deep insert?
  #   Deep Insert
  #     https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#sec_CreateRelatedEntitiesWhenCreatinganE
  #
  ###########
  # Response Codes:
  #   A Create Entity, Create Media Entity, or Invoke Action request that successfully creates a resource returns 201
  #   Created. In this case, the response body MUST contain the resource created.
  #
  ###########
  # SEE:
  #   * https://reso.atlassian.net/wiki/spaces/RESOWebAPIRCP/pages/2239399511/RCP+-+WEBAPI-010+Add+Functionality+to+Web+API+Specification#Example-1---Request
  #   * https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#sec_CreateanEntity
  #   * https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#_Toc31358894
  #
  ###########
  #
  # POST serviceRoot/Property
  #      OData-Version: 4.01
  #      Content-Type: application/json;odata.metadata=minimal
  #      Accept: application/json
  ######################################################################################################################
  @create @create-succeeds @add-edit-endorsement @rcp-010 @1.0.2
  Scenario: Create operation succeeds using a given payload
    Given valid metadata have been retrieved
    And request data has been provided in "create-succeeds.json"
    And request data in "create-succeeds.json" is valid JSON
    And schema in "create-succeeds.json" matches the metadata
    And the request header "OData-Version" "equals" one of the following values
      | 4.0 | 4.01 |
    And the request header "Content-Type" "contains" "application/json"
    And the request header "Accept" "contains" "application/json"
    When a "POST" request is made to the "resource-endpoint" URL with data in "create-succeeds.json"
    Then the server responds with one of the following status codes
      | 201 | 204 |
    And the response header "OData-Version" "equals" one of the following values
      | 4.0 | 4.01 |
    And the response header "EntityId" "MUST" "be present" if the response code was 204
    And the response header "Location" "MUST" "be present"
    And the response header "Location" "is a valid URL"
    And the response header "Location" "MUST" reference the resource being edited
    And the response is valid JSON
    And the JSON response "MAY" contain "@odata.context"
    And the JSON response value "@odata.context" "is a valid URL"
    And the JSON response "MAY" contain "@odata.id"
    And the JSON response value "@odata.id" "is a valid URL"
    And the JSON response "MUST" contain "@odata.editLink"
    And the JSON response value "@odata.editLink" "is a valid URL"
    And the JSON response "MUST" contain all JSON data in "create-succeeds.json"
    When a "GET" request is made to the URL in response header "Location"
    Then the server responds with a status code of 200
    And the response has header "OData-Version" with one of the following values
      | 4.0 | 4.01 |
    And the JSON response contains the data in "create-succeeds.json"
    And the JSON response matches the format advertised in the metadata


  ######################################################################################################################
  # Create Record Fails
  ######################################################################################################################
  # SEE:
  #   * https://reso.atlassian.net/wiki/spaces/RESOWebAPIRCP/pages/2239399511/RCP+-+WEBAPI-010+Add+Functionality+to+Web+API+Specification#Error-Message-Example
  #
  ###########
  # POST serviceRoot/Property
  #      OData-Version: 4.01
  #      Content-Type: application/json
  #      Accept: application/json
  ######################################################################################################################
  @create @create-fails @add-edit-endorsement @rcp-010 @1.0.2
  Scenario: Create operation fails using a given payload
    Given valid metadata have been retrieved
    And request data has been provided in "create-fails.json"
    And request data in "create-fails.json" is valid JSON
    And schema in "create-fails.json" matches the metadata
    And the request header "OData-Version" "equals" one of the following values
      | 4.0 | 4.01 |
    And the request header "Content-Type" "MUST" "be present"
    And the request header "Content-Type" "equals" "application/json"
    And the request header "Accept" "MUST" "be present"
    And the request header "Accept" "contains" "application/json"
    When a "POST" request is made to the "resource-endpoint" URL with data in "create-fails.json"
    Then the server responds with one of the following error codes
      | 400 |
    And the response has header "OData-Version" with one of the following values
      | 4.0 | 4.01 |
    And the error response is in a valid format
    And the values in the "target" field in the JSON payload "error.details" path are contained within the metadata


  ######################################################################################################################
  # Update Record Succeeds
  ######################################################################################################################
  #
  #   >> Discuss, do we support both PUT and PATCH? OData recommends not using PUT due to data loss...
  #   To update an individual entity, the client makes a PATCH or PUT request to a URL that identifies the entity.
  #   Services MAY restrict updates only to requests addressing the edit URL of the entity.
  #
  #   Services SHOULD support PATCH as the preferred means of updating an entity. PATCH provides more resiliency between
  #   clients and services by directly modifying only those values specified by the client.
  #
  #   The semantics of PATCH, as defined in [RFC5789], is to merge the content in the request payload with the
  #   [entity’s] current state, applying the update only to those components specified in the request body.
  #
  #   Collection properties and primitive properties provided in the payload corresponding to updatable properties
  #   MUST replace the value of the corresponding property in the entity or complex type. Missing properties of the
  #   containing entity or complex property, including dynamic properties, MUST NOT be directly altered unless as a
  #   side effect of changes resulting from the provided properties.
  #
  #   Services MAY additionally support PUT but should be aware of the potential for data-loss in round-tripping
  #   properties that the client may not know about in advance, such as open or added properties, or properties not
  #   specified in metadata. Services that support PUT MUST replace all values of structural properties with those
  #   specified in the request body. Missing non-key, updatable structural properties not defined as dependent
  #   properties within a referential constraint MUST be set to their default values. Omitting a non-nullable property
  #   with no service-generated or default value from a PUT request results in a 400 Bad Request error. Missing dynamic
  #   structural properties MUST be removed or set to null.
  #
  #   For requests with an OData-Version header with a value of 4.01 or greater, the media stream of a media entity can
  #   be updated by specifying the base64url-encoded representation of the media stream as a virtual property $value.
  #
  #   Updating a dependent property that is tied to a key property of the principal entity through a referential
  #   constraint updates the relationship to point to the entity with the specified key value.
  #   If there is no such entity, the update fails.
  #
  #   Updating a principle property that is tied to a dependent entity through a referential constraint on the dependent
  #   entity updates the dependent property.
  #
  #   Key and other properties marked as read-only in metadata (including computed properties), as well as dependent
  #   properties that are not tied to key properties of the principal entity, can be omitted from the request.
  #   If the request contains a value for one of these properties, the service MUST ignore that value when applying
  #   the update. Services MUST return an error if an insert or update contains a new value for a property marked as
  #   updatable that cannot currently be changed by the user (i.e., given the state of the object or permissions
  #   of the user). The service MAY return success in this case if the specified value matches the value of the
  #   property. Clients SHOULD use PATCH and specify only those properties intended to be changed.
  #
  #   Entity id and entity type cannot be changed when updating an entity. However, format-specific rules might in some
  #   cases require providing entity id and entity type values in the payload when applying the update.
  #
  #   For requests with an OData-Version header with a value of 4.01 or greater, if the entity representation in the
  #   request body includes an ETag value, the update MUST NOT be performed and SHOULD return 412 Precondition Failed
  #   if the supplied ETag value is not * and does not match the current ETag value for the entity. ETag values in
  #   request bodies MUST be ignored for requests containing an OData-Version header with a value of 4.0.
  #
  #   If an update specifies both a binding to a single-valued navigation property and a dependent property that is
  #   tied to a key property of the principal entity according to the same navigation property, then the dependent
  #   property is ignored, and the relationship is updated according to the value specified in the binding.
  #
  #   If the entity being updated is open, then additional values for properties beyond those specified in the metadata
  #   or returned in a previous request MAY be sent in the request body. The service MUST treat these as dynamic properties.
  #
  #   If the entity being updated is not open, then additional values for properties beyond those specified in the
  #   metadata or returned in a previous request SHOULD NOT be sent in the request body. The service MUST fail if it is
  #   unable to persist all updatable property values specified in the request.
  #
  #   Upon successful completion the service responds with either 200 OK and a representation of the updated entity,
  #   or 204 No Content.
  #
  #   The client may request that the response SHOULD include a body by specifying a Prefer header with a value of
  #   return=representation, or by specifying the system query options $select or $expand.
  #
  #   If the service uses ETags for optimistic concurrency control, the entities in the response MUST include ETags.
  #
  ###########
  # SEE:
  #   * https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#sec_UpdateanEntity
  #   * https://reso.atlassian.net/wiki/spaces/RESOWebAPIRCP/pages/2239399511/RCP+-+WEBAPI-010+Add+Functionality+to+Web+API+Specification#5.3-Examples-for-Updating-Data
  #
  ###########
  # PATCH serviceRoot/Property('12345')
  #   OData-Version: 4.01
  #   Content-Type: application/json;odata.metadata=minimal
  #   Accept: application/json
  #   If-Match: W/\"MjAxOC0wMS0yM1QwODo1Njo0NS4yMi0wODowMA==\"
  #   Prefer: return=representation
  ######################################################################################################################
  @update @update-succeeds @add-edit-endorsement @rcp-010 @1.0.2
  Scenario: Update operation succeeds using a given payload
    Given valid metadata have been retrieved
    And request data has been provided in "update-succeeds.json"
    And request data in "update-succeeds.json" is valid JSON
    And schema in "update-succeeds.json" matches the metadata
    And the request header "OData-Version" "equals" one of the following values
      | 4.0 | 4.01 |
    And the request header "Content-Type" "contains" "application/json"
    And the request header "Accept" "contains" "application/json"
    And the request header "Prefer" "contains" "return=representation"
    When a "PATCH" request is made to the "resource-endpoint" URL with data in "update-succeeds.json"
    Then the server responds with one of the following status codes
      | 200 | 204 |
    And the response header "OData-Version" "equals" one of the following values
      | 4.0 | 4.01 |
    And the response header "EntityId" "MUST" "be present" if the response code was 204
    And the response header "Location" "MUST" "be present"
    And the response header "Location" "is a valid URL"
    And the response header "Location" "MUST" reference the resource being edited
    And the response is valid JSON if the response code was 200
    And the JSON response "MUST" contain "@odata.etag"
    And the JSON response value "@odata.etag" "starts with" "W/"
    And the JSON response "MAY" contain "@odata.context"
    And the JSON response value "@odata.context" "is a valid URL"
    And the JSON response "MAY" contain "@odata.id"
    And the JSON response value "@odata.id" "is a valid URL"
    And the JSON response "MUST" contain "@odata.editLink"
    And the JSON response value "@odata.editLink" "is a valid URL"
    And the JSON response "MUST" contain all JSON data in "update-succeeds.json"
    When a "GET" request is made to the URL in response header "Location"
    Then the server responds with a status code of 200
    And the response has header "OData-Version" with one of the following values
      | 4.0 | 4.01 |
    And the JSON response contains the data in "update-succeeds.json"
    And the JSON response matches the format advertised in the metadata


  ######################################################################################################################
  # Update Record Fails
  ######################################################################################################################
  # SEE:
  #   * https://reso.atlassian.net/wiki/spaces/RESOWebAPIRCP/pages/2239399511/RCP+-+WEBAPI-010+Add+Functionality+to+Web+API+Specification#Error-Message-Example
  #
  ###########
  # PATCH serviceRoot/Property('12345')
  #   OData-Version: 4.01
  #   Content-Type: application/json;odata.metadata=minimal
  #   Accept: application/json
  #   If-Match: W/\"MjAxOC0wMS0yM1QwODo1Njo0NS4yMi0wODowMA==\"
  #   Prefer: return=representation
  ######################################################################################################################
  @update @update-fails @add-edit-endorsement @rcp-010 @1.0.2
  Scenario: Update operation fails using a given payload
    Given valid metadata have been retrieved
    And request data has been provided in "update-fails.json"
    And request data in "update-fails.json" is valid JSON
    And schema in "update-fails.json" matches the metadata
    And the request header "OData-Version" "equals" one of the following values
      | 4.0 | 4.01 |
    And the request header "Content-Type" "MUST" "be present"
    And the request header "Content-Type" "equals" "application/json"
    And the request header "Accept" "MUST" "be present"
    And the request header "Accept" "contains" "application/json"
    When a "PATCH" request is made to the "resource-endpoint" URL with data in "update-fails.json"
    Then the server responds with one of the following error codes
      | 400 |
    And the response has header "OData-Version" with one of the following values
      | 4.0 | 4.01 |
    And the error response is in a valid format
    And the values in the "target" field in the JSON payload "error.details" path are contained within the metadata


  ######################################################################################################################
  # Delete Record Succeeds
  ######################################################################################################################
  #   A successful DELETE request to an entity's edit URL deletes the entity. The request body SHOULD be empty.
  #   Singleton entities cannot be deleted.
  #
  #   On successful completion of the delete, the response MUST be 204 No Content and contain an empty body.
  #
  #   Services MUST implicitly remove relations to and from an entity when deleting it; clients need not delete the relations explicitly.
  ###########
  # SEE:
  #   * http://docs.oasis-open.org/odata/odata/v4.01/csprd04/part1-protocol/odata-v4.01-csprd04-part1-protocol.html#sec_DeleteanEntity
  #   * https://reso.atlassian.net/wiki/spaces/RESOWebAPIRCP/pages/2239399511/RCP+-+WEBAPI-010+Add+Functionality+to+Web+API+Specification#5.3-Examples-for-Deleting-Data
  #
  ###########
  # DELETE serviceRoot/Property('12345')
  #   OData-Version: 4.01
  #   If-Match: W/\"MjAxOC0wMS0yM1QwODo1Njo0NS4yMi0wODowMA==\"
  ######################################################################################################################
  @delete @update-succeeds @add-edit-endorsement @rcp-010 @1.0.2
  Scenario: Delete operation succeeds using a given Url
    Given valid metadata have been retrieved
    And the request header "OData-Version" "equals" one of the following values
      | 4.0 | 4.01 |
    When a "DELETE" request is made to the "resource-endpoint" URL with data in "delete-succeeds.json"
    Then the server responds with one of the following status codes
      | 204 |
    And the response header "OData-Version" "equals" one of the following values
      | 4.0 | 4.01 |
    And the response is valid JSON
    And the JSON response "MUST" be empty
    When a "GET" request is made to the URL in response header "Location"
    Then the server responds with a status code of 404
    And the response has header "OData-Version" with one of the following values
      | 4.0 | 4.01 |


  ######################################################################################################################
  # Delete Record Fails
  ######################################################################################################################
  # SEE:
  #   * https://reso.atlassian.net/wiki/spaces/RESOWebAPIRCP/pages/2239399511/RCP+-+WEBAPI-010+Add+Functionality+to+Web+API+Specification#Error-Message-Example
  #
  ###########
  # DELETE serviceRoot/Property('12345')
  #   OData-Version: 4.01
  #   If-Match: W/\"MjAxOC0wMS0yM1QwODo1Njo0NS4yMi0wODowMA==\"
  ######################################################################################################################
  @delete @delete-fails @add-edit-endorsement @rcp-010 @1.0.2
  Scenario: Delete operation fails using a given Url
    Given valid metadata have been retrieved
    And the request header "OData-Version" "equals" one of the following values
      | 4.0 | 4.01 |
    When a "DELETE" request is made to the "resource-endpoint" URL with data in "delete-fails.json"
    Then the server responds with a status code between 400 and 499
    And the response header "OData-Version" "equals" one of the following values
      | 4.0 | 4.01 |

Feel free to make suggestions, change things entirely, ask questions, clean things up, or add things. We'll discuss this further in the Transport and Certification Groups in March-April 2021.

cc: @EnFinlay @dgmyrek @SergioDelRioT4Bi @psftc @RESOStandards/employees

[darnjo]

Was thinking about it further and I think that we'd probably want one test per http code that could be returned. So, we'd have a success case for 200 as well as 201 and whatever other 200 status codes we have.

We'd probably have something similar for non-200 status codes, but I think we can be less specific there (by saying non-200) except in cases where a specific code is expected.

[gr33neggs]

I think @odata.id should be a MAY as well:

https://docs.oasis-open.org/odata/odata-json-format/v4.01/odata-json-format-v4.01.html#sec_ControlInformationidodataid

The id control information MUST appear in responses if metadata=full is requested, or if metadata=minimal is requested and any of a non-transient entity's key fields are omitted from the response or the entity-id is not identical to the canonical URL of the entity after

· IRI-to-URI conversion as defined in [RFC3987],
· relative resolution as defined in section 5.2 of [RFC3986], and
· percent-encoding normalization as defined in section 6 of [RFC3986].

Assuming of course that metadata=minimal is still the default unless otherwise specified. OData 4.0 stated that it is the default, but the text was removed from OData 4.01

4.0: http://docs.oasis-open.org/odata/odata-json-format/v4.0/os/odata-json-format-v4.0-os.html#_Toc372793041

The odata.metadata=minimal format parameter indicates that the service SHOULD remove computable control information from the payload wherever possible. This is the default value for the odata.metadata parameter and will be assumed if no other value is specified in the Accept header or $format query option. The response payload MUST contain at least the following common annotations:

4.01 https://docs.oasis-open.org/odata/odata-json-format/v4.01/odata-json-format-v4.01.html#sec_metadataminimalodatametadataminimal

[SergioDelRioT4Bi]

On testing as a whole, I think the above is a great starting point. It might have to change after we start testing servers, but it's going to be very hard to know that until we do start the testing. So, I am in favour of going forward with the testing rules above.

[dgmyrek]

If the writeup above is still current/relevant, I have a concern:

18. MUST include edit links (explicitly or implicitly) for all updatable or deletable resources according to [OData-JSON]
19. MUST support DELETE to all edit URLs for deletable resources (section 11.4.5)

Supporting DELETE should be a MAY instead of a MUST for a couple of reasons:

1. There are instances where our MLS customers wish to grant write access to certain records or field subsets of those records, yet they don't trust the operating party with full control. This may point to a larger limitation of the current spec as a whole, as it doesn't appear to allow for that level of granularity - edit URLs seem to be all or nothing.
2. On the server side, some resources simply can't support DELETE in the conventional sense, yet the server provider may wish for these resources to still be editable.

[darnjo]

Hi Dylan.

The testing rules that were approved are in the in-progress specifications here: https://github.com/RESOStandards/transport/blob/rcp-010-updated-draft-specification/web-api-add-edit.md

You may want to review and comment on the ticket, which is located here: #4

[dgmyrek]

Thanks Josh, will do.

[darnjo]

No problem, Dylan. Feel free to comment or reach out if you have additional questions.

The portion of the specification related to Delete is here, and the approved testing rules are here.

I think we've avoided the scenarios you asked about, and it's important to note that providers MAY implement any of the Create, Update, or Delete actions as they see fit. None of them are required.

Therefore, if someone wanted to implement Update on a single field like PublicRemarks, they only need to show that Update works for a known-good payload and fails for a known-bad one, in which case it needs to produce error messages in the appropriate format. The single field could either be standard or local as well. Of course it could be more than that too...