| 21 | | === Custom Methods Plugged into REST === |
| 22 | | In many cases it may be much easier to implement non-CRUD resource functions as REST-plugins instead of separate controllers. |
| 23 | | * see search_simple for an example |
| 24 | | |
| 25 | | The advantage of doing it as REST plugin is that you have a pre-parsed XRequest instead of the original request, as well as you'd preserve the actions and setting from your REST interface for this resource. |
| 26 | | |
| 27 | | XRequest is already checked and parsed for the REST syntax, and is resolved for the format extension (XRequest.representation) and record ID's, contains all handles to the necessary tables as well as the complete primary record (if any). |
| 28 | | |
| 29 | | It contains the interface to export or import the resource in XML and JSON (.import_xml() and .export_xml() resp. _json()), and of course you'd have the nice backlink helpers to quickly produce URL's: |
| 30 | | {{{ |
| 31 | | .here() (=URL of the current resource), |
| 32 | | .same() (=URL of the current resource, record ID replaced as "[id]"), |
| 33 | | .there() (=URL of the current resource, no function, no record ID), and |
| 34 | | .other() (=URL of the current resource, other function) |
| 35 | | }}} |
| 36 | | and finally, XRequest remembers the record ID until the next request to the same resource in the same session, which can be helpful when producing links (especially _next's) not knowing the record ID. |
