Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the description of REST vs OCS in accordance to sugestions discussed #12264

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 19 additions & 4 deletions developer_manual/basics/controllers.rst
Original file line number Diff line number Diff line change
Expand Up @@ -382,6 +382,8 @@ Because returning JSON is such a common task, there's even a shorter way to do t

Why does this work? Because the dispatcher sees that the controller did not return a subclass of a Response and asks the controller to turn the value into a Response. That's where responders come in.

.. _controller-responders:

Responders
^^^^^^^^^^

Expand Down Expand Up @@ -732,10 +734,15 @@ The following policy for instance allows images, audio and videos from other dom
OCS
^^^

.. note:: This is purely for compatibility reasons. If you are planning to offer an external API, go for a :doc:`../digging_deeper/rest_apis` instead.
In order to simplify exchange of data between the Nextcloud backend and any client (be it the web frontend or whatever else), the OCS API has been introduced.
Here, JSON and XML responders have been prepared and are installed without additional effort.

In order to ease migration from OCS API routes to the App Framework, an additional controller and response have been added. To migrate your API you can use the **OCP\\AppFramework\\OCSController** base class and return your data in the form of a DataResponse in the following way:
.. note::
The usage of OCS is closely related to the usage of :doc:`../digging_deeper/rest_apis`.
Unless you have a clear use-case, it is advised to use OCS over pure REST.
A more detailed description can be found in :ref:`ocs-vs-rest`.

To use OCS in your API you can use the **OCP\\AppFramework\\OCSController** base class and return your data in the form of a **DataResponse** in the following way:

.. code-block:: php

Expand All @@ -757,9 +764,13 @@ In order to ease migration from OCS API routes to the App Framework, an addition

}

The format parameter works out of the box, no intervention is required.
For ``OCSController`` classes and their methods, :ref:`responders <controller-responders>` can be registered as with any other ``Controller`` method.
The ``OCSController`` class have however automatically two respo nders pre-installed:
Both JSON (``application/json``) and XML (``text/xml``) are generated on-the-fly depending on the request by the browser/user.
To select the output format, the format parameter or the ``Accept`` header of the request work out of the box, no intervention is required.
It is advised to prefer the header generally, as this is the more programmatic way.

In order to make routing work for OCS routes you need to add a separate 'ocs' entry to the routing table of your app.
In order to make routing work for OCS routes you need to add a separate 'ocs' entry to the routing table in ``appinf/routes.php`` of your app.
Inside these are normal routes.

.. code-block:: php
Expand All @@ -778,6 +789,10 @@ Inside these are normal routes.

Now your method will be reachable via ``<server>/ocs/v2.php/apps/<APPNAME>/api/v1/shares``

.. versionadded:: 29
You can use the attribute ``ApiRoute`` as described in :doc:`Routing <routing>` instead of the entry in ``appinfo/routes.php`` as an alternative.


Handling errors
^^^^^^^^^^^^^^^

Expand Down
2 changes: 1 addition & 1 deletion developer_manual/conf.py
Original file line number Diff line number Diff line change
Expand Up @@ -183,7 +183,7 @@
#'pointsize': '10pt',

# Additional stuff for the LaTeX preamble.
'preamble': '\extrafloats{100}\maxdeadcycles=500\DeclareUnicodeCharacter{274C}{\sffamily X}',
'preamble': '\\extrafloats{100}\\maxdeadcycles=500\\DeclareUnicodeCharacter{274C}{\\sffamily X}',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👀

}

# Grouping the document tree into LaTeX files. List of tuples
Expand Down
75 changes: 73 additions & 2 deletions developer_manual/digging_deeper/rest_apis.rst
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,8 @@ REST APIs

.. sectionauthor:: Bernhard Posselt <dev@bernhard-posselt.com>

Offering a RESTful API is not different from creating a :doc:`route <../basics/routing>` and :doc:`controllers <../basics/controllers>` for the web interface. It is recommended though to inherit from ApiController and add **@CORS** annotations to the methods so that `web applications will also be able to access the API <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS>`_.
Offering a RESTful API is not different from creating a :doc:`route <../basics/routing>` and :doc:`controllers <../basics/controllers>` for the web interface.
It is recommended though to inherit from ApiController and add **@CORS** annotations to the methods so that `web applications will also be able to access the API <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS>`_.
Comment on lines -9 to +10
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No relevant diff?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just styling to put every sentence on it's own line. I can drop that as well.


.. code-block:: php

Expand Down Expand Up @@ -44,7 +45,8 @@ CORS also needs a separate URL for the preflighted **OPTIONS** request that can
)


Keep in mind that multiple apps will likely depend on the API interface once it is published and they will move at different speeds to react to changes implemented in the API. Therefore it is recommended to version the API in the URL to not break existing apps when backwards incompatible changes are introduced::
Keep in mind that multiple apps will likely depend on the API interface once it is published and they will move at different speeds to react to changes implemented in the API.
Therefore it is recommended to version the API in the URL to not break existing apps when backwards incompatible changes are introduced::
Comment on lines -47 to +49
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here


/index.php/apps/myapp/api/1.0/resource

Expand Down Expand Up @@ -79,3 +81,72 @@ To add an additional method or header or allow less headers, simply pass additio
}

}

.. _ocs-vs-rest:

Relation of REST and OCS
------------------------

There is a close relationship between REST APIs and :ref:`OCS <ocscontroller>`.
Both provide a way to transmit data between the backend of the app in the Nextcloud server and some frontend.

The following combinations of attributes might be relevant for various scenarios:

#. Plain frontend route: ``Controller`` class
#. Plain Frontend with CRSF checks disabled: ``Controller`` class and ``#[NoCSRFRequired]`` attribute on the method
#. OCS-based route: ``OCSController`` class
#. OCS-based route with CSRF disabled: ``OCSController`` class and ``#[NoCSRFRequired]`` attribute on the method
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this case doesn't exist, NoCSRFRequired should not have an effect on OCSController, but I will have to check that in the code to be sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking back and forth on this as well. In the end, I decided to keep the case as there is a certain difference (at least from the implementation):

For methods with NoCSRFRequired, this section is doing nothing.

For the case where the attribute is not given, the strict cookie check boils down to a check on the OCS-APIREQUEST header or no valid session token.

With the header in place (as the OCS controller generally expects), the second part is also skipped: The CSRF check is hardcoded to true, thus isInvalidCSRFRequired returns false.

When the header is not set, you enter the second if block and will check the inner if. The check isinstance OCSController is obviously true. The isValidOCSRequest is somewhat redundant as it can only be reached with the header unset. Alternatively, a bearer authorization header is sufficient to make the CSRF checker happy (even without OCS header and without NoCSRFRequired attribute).

I was adding this case as a reaction on your statement

There is another case with OCS+CSRF

In my opinion the last case could be dropped (and was never planned in the first round) but I do not see clearly the motivation of it, to be honest. Did I misunderstand your statement above?


.. warning::
Adding the ``#[NoCRSFRequired]`` attribute imposes a security risk.
You should not add this to your controller methods unless you understand the implications and be sure that you absolutely need the attribute.

There are different ways a clients might interact with your APIs.
These ways depend on your API configuration (what you allow) and on which route the request is finally made.

- *Access from web frontend* means the user is browses the Nextcloud web frontend with a browser.
- *Access from an external app* indicates that the user is not using the normal browser (as logged in) but directly navigates a certain URL.
This can be in a new browser tab or an external program (like an Android app or simply a curl command line).

.. list-table:: Comparison of different API types
:header-rows: 1
:align: center

* - Description
- 1 (plain)
- 2 (w/o CSRF)
- 4 (OCS)
- 4 (OCS w/o CSRF)
* - URL prefix (relative to server)
- ``/apps/<appid>/``
- ``/apps/<appid>/``
- ``/ocs/v2.php/apps/<appid>/``
- ``/ocs/v2.php/apps/<appid>/``
* - Access from web frontend
- yes
- yes (CSRF risk)
- yes
- yes (CSRF risk)
* - Access from external app
- ---
- yes
- yes (with header [#]_)
- yes
christianlupus marked this conversation as resolved.
Show resolved Hide resolved
* - Encapsulated data
- no
- no
- yes (JSON or XML)
- yes (JSON or XML)

Methods from ``Controller`` classes can return ``DataResponse`` objects similar to ``OCSController`` class methods.
For methods of a ``Controller`` class, the data of this response is sent e.g. as JSON as you provide it.
Basically, the output is very similar to what ``json_encode`` would do.
In contrast, the OCS controller will encapsulate the data in an outer shell that provides some more (meta) information.
For example a status code (similar to the HTTP status code) is transmitted at top level.
The actual data is transmitted in the ``data`` property.

As a rule of thumb one can conclude that OCS provides a good way to handle most use cases including sufficient security checks.
The only exception to this is if you want to provide an API for external usage where you have to comply with an externally defined API scheme.
Here, the encapsulation introduced in OCS and CSRF checks might be in your way.

.. [#] The OCS controller needs the request header ``OCS-APIREQUEST`` to be set to ``true``.