administrator, editor
1
edit
Changes
Jump to navigation
Jump to search
m
* Quality factors in the [[#Content Negotiation|Accept header]] will be evaluated
update custom response according to spec. Hopefully BaseX implemented it this way
* Parameters are implicitly cast to the type of the function argument
* The [[#Paths|Path Annotation]] can contain regular expressions
* <code>%input</code> annotations, support for input-specific content-type parameters
* <code>%rest:single</code> annotation to cancel running RESTXQ functions
* Quality factors in the [[#Content Negotiation|Accept header]] will be evaluated
* {{Version|9.0}}: Support for server-side quality factors in the [[#Content Negotiation|<code>%rest:produces</code>]] annotation
<br />
Two following annotations can be used to restrict functions to specific content types:
* '''HTTP Content Types''': a A function will only be invoked if the HTTP {{Code|Content-Type}} header of the request matches one of the given mime content types. Example:
<pre class="brush:xquery">%rest:consumes("application/xml", "text/xml")</pre>
* '''HTTP Accept''': a A function will only be invoked if the HTTP {{Code|Accept}} header of the request matches one of the defined mime content types. Example:
<pre class="brush:xquery">%rest:produces("application/atom+xml")</pre>
By default, both mime content types are {{Code|*/*}}. Quality factors supplied by a client will also be considered in the path selection process.If a client supplies the following accept header…
<pre>
</pre>
…and if two RESTXQ functions exist with the same {{Code|path}} annotation and , one with the {{Code|produces}} annotations annotation <code>*/*</code> , and another with <code>text/html</code>, respectively, the second function with the second annotation will be called, because the quality factor for <code>text/html</code> documents is higher than the one for arbitrary other mime typeshighest.
With {{Version|9.0}}, support for server-side quality factors was added. If multiple function candidates are left over after the above steps, the <code>qs</code> parameter will be considered. The function with the highest quality factor will be favored: <pre class="brush:xquery">%rest:produces("text/html;qs=1")%rest:produces("*/*;qs=0.8")</pre> Note that this the annotation will ''not'' affect the content-type of the HTTP actual response. Instead, you You will need to add a supply an additional <code>[[#Output|%output:media-type]]</code> annotation.
===HTTP Methods===
==Query Execution==
{{Mark|Updated with Version 9.0:}}: The dubious old status code {{Code|410}} (which indicates to the client that a resource is permanently removed) was replaced with {{Code|460}}.
In many RESTXQ search scenarios, input from browser forms is processed and search results are returned. User experience can generally be made more interactive if an updated search request is triggered with each key click. However, this may lead to many expensive parallel requests, from which only the result of the last request will be relevant for the client.
declare %rest:path("") function page:error404() {
<rest:response>
<http:response status="404" messagereason="I was not found.">
<http:header name="Content-Language" value="en"/>
<http:header name="Content-Type" value="text/html; charset=utf-8"/>
};
</pre>
=User Authentication=
If you want to provide restricted access to parts of a web applications, you will need to check permissions before returning a response to the client. With {{Version|9.0}} of BaseX, a [[Permissions]] layer was introduced to facilitate permission checks.
=Functions=
;Version 9.0
* Added: Support for server-side quality factors in the [[#Content Negotiation|<code>%rest:produces</code>]] annotation* Updated: The dubious status Status code {{Code|410}} (which indicates that a resource is permanently removed) was replaced with {{Code|460}}* Removed: {{Code|restxq}} prefix
;Version 8.4
