Implement ETag & Last-modified

[brantje]

This will greatly speed up the api.
For reference we can use this.
Shouldn't be too difficult.
@ThomasDaheim Want to give this a try? If you want to, make sure you branch of the master branch.

cc @korelstar Can you guide us along the way?

[ThomasDaheim]

Will have a look at that. From the first glance it seems to be incompatible with folder mode since it needs to store data per note in the database?

[brantje]

Afaik, the notes app is using files. I'll dig a bit into it later.

[ThomasDaheim]

Well, they now also use a database for metadata. Maybe thats something we could live with.

[ThomasDaheim]

Would want do clone the notes repo anyways to see how the resolved "$note->getId()" in case only files are used. Not sure where you would store an id in that case...

[brantje]

getId() returns always an int.

[ThomasDaheim]

Yes, have seen that. Its somehow info stored by nextcloud along with the file. So it should be relatively easy to retrieve it for a file and (hopefully) also find the file for an id :-)

[ThomasDaheim]

BTW, how could this be easily tested once added as feature? I don't know to much about testing in such an environment...

[brantje]

I think if we follow this:

## API-Changes

**1. Don't transfer data if nothing has changed (`ETag`/`If-None-Match`)**

The server now sends the HTTP header field `ETag`, which is a hash value of the server response. After processing the server response, clients should save this value locally and send the HTTP header `If-None-Match` using the saved value in their next request to the server. If the server wants to response with the same data, it will send `304 Not Modified` without any data instead. This behavior is conform to the HTTP standard and fully backward compatible.

**2. Only transfer changed data, if something has changed (`pruneBefore`)**

If only a single note is changed (edited or deleted), we nevertheless don't want to transfer all notes again. Therefore, the server response includes the HTTP header `Last-Modified`. After processing the server response, clients should save this value locally and use the parameter `pruneBefore` in their next request to the server. Then, the server prunes all notes which where changed before this date (i.e. only their `id` is transferred). With this approach, clients are able to update changed notes and also remove deleted notes while reducing the transferred data size significantly. This behavior is fully backward compatible.

It should be fine, otherwise i hope that @korelstar could help a bit out.

[ThomasDaheim]

Long time no progress here. By now I have managed to upgrade my NAS so that its fast enough for development & testing.

I would think this is a feature to add after v1.0 is ready? Stable first - fast later :-) Or is that an essential feature right away?