commit 00e8a27386b8db078823194b91163cae8a03fcde
author Edwin Kempin <ekempin@google.com> Wed Jul 11 17:48:42 2018 +0200
committer Edwin Kempin <ekempin@google.com> Wed Jul 18 10:38:07 2018 +0200
tree cf6ba527617dc20113b95c0a10afaad686935976
parent 181b0bbd367e5784cb507e07fe7111a4d84c3937

RestApiModule: Support binding a RestView to delete a missing resource

A change edit can be created by deleting a file (that exists in the
change) from the non-existing change edit:

  DELETE /changes/<change-id>/edit/<file-path>

The same request is also used to delete the content of the specified
file from an existing change edit.

Technically what happens is that:

1. The ChangeEdits RestCollection is asked to parse the <file-path>
2. If the change edit and the file in the change exist, a
   ChangeEditResource(*) is returned, if the change edit doesn't exist
   the 'parse' method throws a ResourceNotFoundException (indicating
   that the member wasn't found)
3a. If the ChangeEditResource was returned, we find the RestView that is
    bound for DELETE on ChangeEditResources and let it handle the
    request.
3b. If a ResourceNotFoundException was thrown, we catch the exception
    and check if the RestCollection implements AcceptsDelete and if yes,
    we invoke the 'delete' method to *create* the change edit and to
    delete the member from it.

(*) Note that ChangeEditResource represents 2 kind of resources
    (according to its JavaDoc), the change edit itself and a file within
    the change edit.

I find 3b. pretty confusing and would have preferred that this use case
would have required two calls, one to create the change edit, and one to
delete the file in the *existing* change edit, but now it's hard to
change without breaking anything.

To make this logic easier to understand RestApiModule now offers to bind
a RestDeleteMissingView for DELETE requests that should be handled on
missing collection members (similar to how a RestCreateView can be bound
for resource creation by PUT and POST, see change I5cd61f77a).

This is the first step to remove the AcceptsDelete interface. The other
use case for the AcceptsDelete interface is to support DELETE on the
RestCollection itself. Gerrit core doesn't use this functionality but
plugins may rely on it. Hence for now AcceptsDelete is kept for this
purpose. It's planned to support this use case by REST bindings too, but
this will be implemented by a follow-up change (similar to how POST on
RestCollection is supported now, see change Iea3b8e9800).

This change improves code readability since by reading the Module class
we can now directly see which REST collections support DELETE on missing
members.

The ChangesRestApiBindingsIT.changeEditCreateEndpoints test verifies
that the REST request for creating a change edit by DELETE is correctly
resolved to a REST endpoint implementation.

Change-Id: If64224d502bbfe578133d1255b42902dd4fbe4fb
Signed-off-by: Edwin Kempin <ekempin@google.com>