Update the Query 3.0 specification to state:
1) An implementation SHOULD support POST with application/x-www-form-urlencoded (including the reasons for doing so) and include an example of such usage.
2) If query paging is supported, clients SHOULD consider URI lengths and to get a page of query results, and if too long, SHOULD use a POST with application/x-www-form-urlencoded with the URI's query parameters.Update the Query 3.0 specification to state: 1) An implementation SHOULD support POST with application/x-www-form-urlencoded (including the reasons for doing so) and include an example of such usage. 2) If query paging is supported, clients SHOULD consider URI lengths and to get a page of query results, and if too long, SHOULD use a POST with application/x-www-form-urlencoded with the URI's query parameters.
Proposal accepted vt ballot https://www.oasis-open.org/apps/org/workgroup/oslc-core/ballot.php?id=3165. The draft OSLC Query spec has been updated with the proposed changes.
The obsolete document at https://open-services.net/bin/view/Main/OslcSimpleQuerySemanticsV1 it references says:
"However, if the query parameters are very long, it may be preferable to instead request the result of the query by sending an HTTP POST request to the base URL and include the query parameters in the HTTP request body as content with media type application/x-www-form-urlencoded. In REST parlance, this is sometimes refered to as an overloaded POST. In the following sections we'll normally talk about appending query parameters to the base URL to form a query URL, and sending an HTTP GET request to the query URL with the understanding that similar statements apply to the HTTP POST case."
It's not clear whether the POST alternative for query is meant to be part of the spec or not.
"A Query Capability describes a query capability, capable of querying resources via HTTP GET or POST. " without describing any usage for POST.
The description of oslc:queryBase is "The base URI to use for queries. Queries are invoked via HTTP GET on a query URI formed by appending a key=value pair to the base URI, as described in Query Capabilities section." which doesn't mention POST.
The section "Query Capabilities" and its subsections only describe GET.
The issue here is that the URI for a GET of the query base URI could be too long. It's common to have limits of 2048 on URI lengthj. If a client needs to define lots of namespaces in oslc.prefix, and/or complex oslc.where and/or oslc.select, the resultant URI could exceed those limits. The usual recommendation in those cases is for a server to support a POST endpoint with x-www-form-urlencoded POST body. Experimentation shows you don't get this for free. You have to implement a specific method to handle the POST. For example, using Juno:
path="/" + ConfigurationFrontServiceConstants.RESOLVE_COMPONENTS,
description="Resolves components in a global configuration context.")
This also relates to OSLC paging for query results. If an implementation is stateless, the request to get the next page will need to include most of the query parameters like oslc.where, oslc.select, oslc.prefix as well as some additional ones to start at some offset. The OSLC paging description in core does not address this issue, implying that it's always a GET.