Fix typos and delete examples folder in response to review.

Author: rwb27

README.md

@@ -46,7 +46,7 @@ All changes to the codebase should go via pull requests, and should only be merg
 
 ## Demo
 
-See [readthecods] for a runnable demo.
+See [readthedocs] for a runnable demo.
 
 [Web of Things]: https://www.w3.org/WoT/
 [python-labthings]: https://github.com/labthings/python-labthings/

docs/source/examples.rst

@@ -0,0 +1,9 @@
+Examples
+========
+
+For a simple example `.Thing` and instructions on how to serve it, see the :ref:`tutorial`\ .
+
+For more complex examples, there is a useful collection of `.Thing` subclasses implemented as part of the `OpenFlexure Microscope`_ in the `things`_ submodule. This includes control of a camera and a translation stage, as well as various software `.Thing`\ s that integrate the two.
+
+.. _`OpenFlexure Microscope`: https://gitlab.com/openflexure/openflexure-microscope-server/
+.. _`things`: https://gitlab.com/openflexure/openflexure-microscope-server/-/tree/v3/src/openflexure_microscope_server/things/

docs/source/index.rst

@@ -9,6 +9,7 @@ Documentation for LabThings-FastAPI
    wot_core_concepts.rst
    lt_core_concepts.rst
    tutorial/index.rst
+   examples.rst
    actions.rst
    dependencies/dependencies.rst
    blobs.rst

docs/source/using_things.rst

@@ -37,7 +37,7 @@ Planned future development: static code generation
 
 In the future, `labthings_fastapi` will generate custom client subclasses. These will have the methods and properties defined in a Python module, including type annotations. This will allow static analysis (e.g. with MyPy) and IDE autocompletion to work. Most packages that provide a `Thing` subclass will want to release a client package that is generated automatically in this way. The intention is to make it possible to add custom Python code to this client, for example to handle specialised return types more gracefully or add convenience methods. Generated client code does mean there will be more packages to install on the client in order to use a particular Thing. However, the significant benefits of having a properly defined interface should make this worthwhile.
 
-Return types are also currently not consistent between client and server code: currently, the HTTP implementation of `.ThingClient` deserialises the JSON response and returns it directly, meaning that `pydantic.BaseModel` subclasses become dictionaries. This behaviour should change in the future to be consistent between client and server. Most liekly, this will mean Pydantic models are used in both cases.
+Return types are also currently not consistent between client and server code: currently, the HTTP implementation of `.ThingClient` deserialises the JSON response and returns it directly, meaning that `pydantic.BaseModel` subclasses become dictionaries. This behaviour should change in the future to be consistent between client and server. Most likely, this will mean Pydantic models are used in both cases.