| 55 | | 2. Submission of the search-form collects these URL filters (client-side) and |
| 56 | | then sends them with a GET-request to the REST-API, either as Ajax or as full |
| 57 | | page request (=window.open). This request does not go to the /search method, |
| 58 | | but instead to the respective representation method (e.g. /report, /list, /map), without need for those method |
| 59 | | handlers to process the filters: they can simply assume that they get a pre- |
| 60 | | filtered resource. |
| | 53 | 2. Submission of the search-form collects these URL filters (client-side) and then sends them with a GET-request to the REST-API, either as Ajax or as full page request (=window.open). This request does not go to the /search method, but instead to the respective representation method (e.g. /report, /list, /map), without need for those method handlers to process the filters: they can simply assume that they get a pre-filtered resource. |
| 62 | | 3. The REST-API would then pre-filter the resource, and then hand it over to |
| 63 | | the requested method handler - map, list, report or whatever and in whatever |
| 64 | | data format (=RESTful request as usual). Whether this is Ajax or not depends |
| 65 | | entirely on the client-side implementation - it could be either. It could even |
| 66 | | be neither, but instead a web service request (e.g. from mobile clients, or |
| 67 | | from an external site) - which leads directly to point 4: |
| | 55 | 3. The REST-API would then pre-filter the resource, and then hand it over to the requested method handler - map, list, report or whatever and in whatever data format (=RESTful request as usual). Whether this is Ajax or not depends entirely on the client-side implementation - it could be either. It could even be neither, but instead a web service request (e.g. from mobile clients, or from an external site) - which leads directly to point 4: |
| 69 | | 4. SearchWidgets/-forms can be requested directly from the REST-API (from the |
| 70 | | re-defined /search method) - so that they can be embedded everywhere - and get loaded |
| 71 | | asynchronously. Since they are processed client-side, there's no need to keep any formkeys or |
| 72 | | session variables. This GET /search method can also include loading of saved |
| 73 | | searches, and the POST /search method would then only serve for save |
| 74 | | search/subscription (which actually makes sense from the REST perspective), |
| 75 | | but not for processing the search. |
| | 57 | 4. SearchWidgets/-forms can be requested directly from the REST-API (from the re-defined /search method) - so that they can be embedded everywhere - and get loaded asynchronously. Since they are processed client-side, there's no need to keep any formkeys or session variables. This GET /search method can also include loading of saved searches, and the POST /search method would then only serve for save search/subscription (which actually makes sense from the REST perspective), but not for processing the search. |
| 77 | | I know that this requires a fair bit of framework client-side (somewhat a |
| 78 | | client-side pendant for S3Resource), but this is something we might need |
| 79 | | anyway. |
| 80 | | |
| 81 | | 2) Search-forms can be requested from the REST API using the GET /search |
| 82 | | method. That way, they can be embedded in every page - and get loaded |
| 83 | | asynchronously. Since search forms would never get submitted to the server, |
| 84 | | there is no need to store anything server-side anymore. |
| | 59 | This requires a fair bit of framework client-side (somewhat a client-side pendant for S3Resource), but this is something we might need anyway. |
