Mercurial Repository: p/roundup/code: doc/rest.txt comparison

comparison doc/rest.txt @ 5863:e0df29c18be8

Merge changes

author	Ralf Schlatterbeck <rsc@runtux.com>
date	Mon, 26 Aug 2019 08:13:46 +0200
parents	a0eaae3f638b d5aed7106ee6
children	04deafac71ab

comparison

equal deleted inserted replaced

-:a0eaae3f638b
+:e0df29c18be8
 well as a ``collections`` list of objects::
 { "data": {
 "meta data field1": "value",
 "meta data field2": "value",
-"collecton": [
+"collection": [
 { "link": "url to item",
 "id": "internal identifier for item" },
 	    { "link": "url to second item",
 "id": "id item 2" },
 ... ]
 "relation2": [ {...} ], ...
 }
 }
 }
-available meta data is described in the documention for the
+available meta data is described in the documentation for the
 collections endpoint.
 The ``link`` fields implement HATEOS by supplying a url for the
 resource represented by that object. The "link" parameter with the
 value of a url is a special case of the @links parameter.
 the issue. Example::
 { "data": {
 "meta data field1": "value",
 "type": "type of item, issue, user ..."
-"link": "link to retreive item",
+"link": "link to retrieve item",
 "attributes": {
 "title": "title of issue",
 "nosy": [
 	            { "link": "url for user4",
 "id": "4" }
 }
 Using a property endpoint (e.g. title or nosy list for an issue) the
 ``data`` wrapper has a ``data`` subfield that represents the value of
 the property. This ``data`` subfield may be a simple string (all types
-except mutlilink) or a list of strings (multilink
+except multilink) or a list of strings (multilink
 properties). Example::
 { "data": {
 "type": "description of class",
 "@etag": "\"f15e6942f00a41960de45f9413684591\"",
-"link": "link to retreive property",
+"link": "link to retrieve property",
 "id": "id for object with this property",
 "data": "value of property"
 }
 }
 ``https://.../rest/data/keyword?name=foo`` (note searching keyword
 class not issue class) will return matches for ``foo``, ``foobar``,
 ``foo taz`` etc.
 In all cases the field ``@total_size`` is reported which is the total
-number of items available if you were to retreive all of them.
+number of items available if you were to retrieve all of them.
 Other data types: Date, Interval Integer, Number need examples and may
 need work to allow range searches. Full text search (e.g. over the
 body of msgs) is a work in progress.
 ``@page_size`` is specified, all matching items are returned.
 * - ``@page_index``
 - (which defaults to 1 if not given) specifies which page number
 of ``@page_size`` items is displayed.
-Also when pagenation is enabled the returned data include pagenation
+Also when pagination is enabled the returned data include pagination
 links along side the collection data. This looks like::
 { "data":
 {
 "collection": { ... },
 * - Query parameter
 - Explanation
 * - ``@verbose=0``
 - each item in the collection has its "id" property displayed
-and a link with the URL to retreive the item.
+and a link with the URL to retrieve the item.
 * - ``@verbose=1``
 - for collections this output is the same as ``@verbose=0``. This
 is the default.
 * - ``@verbose=2``
 - each item in the collection includes the "label" property in
 Note that the ``link`` field that is returned doesn't exist in the
 database. It is a construct of the rest interface. This means that you
 can not set ``@fields=link`` and get the link property included in the
 output.
-Also using ``@fields=@etag`` will not work to retreive the etag for
+Also using ``@fields=@etag`` will not work to retrieve the etag for
 items in the collection.
 See the `Searches and selection`_ section for the use cases supported
 by these features.
 the fields you are interested in reducing network load as well as
 memory and parsing time on the client side. By default protected
 properties (read only in the database) are not listed. Th
 is makes it easier to submit the attributes from a
 ``@verbose=0`` query using PUT. To include protected properties
-in the output og a GET add the query parameter
+in the output of a GET add the query parameter
 ``@protected=true`` to the query and attributes like: actor,
 created, creator and activity will be include in the result.
 Link and Multilink properties are displayed as a dictionary with a
 ``link`` and an ``id`` property by default. This is controlled by the
 The ``PATCH`` method can be applied to properties, e.g.,
 ``/data/issue/42/title``.  This method gets an operator
 ``@op=<method>`` where ``<method>`` is one of ``add``, ``replace``,
 ``remove``. If no operator is specified, the default is ``replace``
 which is the same as performing a PUT on the field url. ``add`` and
-``remove`` allow ading and removing values from MultiLink
+``remove`` allow adding and removing values from MultiLink
 properties. This is easier than having to rewrite the entire value for
 the field using the ``replace`` operator or doing a PUT to the field.
 On success the returned value is the same as the respective ``GET``
 method.
 Tunneling Methods via POST
 ==========================
 If you are working through a proxy and unable to use http method like
 PUT, PATCH or DELETE you can use POST to perform the action. To tunnel
-an action throught POST, send the ``X-HTTP-METHOD-OVERRIDE`` header
+an action through POST, send the ``X-HTTP-METHOD-OVERRIDE`` header
 with a value of DELETE or other capitalized HTTP verb. The body of the
 POST should be what you would send if you were using the method
 without tunneling.
 Examples and Use Cases

Mercurial > p > roundup > code

comparison doc/rest.txt @ 5863:e0df29c18be8