OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (OSLCCORE-124) Query spec doesn't say whether POST with application/x-www-form-urlencoded should be supported


    [ https://issues.oasis-open.org/browse/OSLCCORE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=68799#comment-68799 ] 

James Amsden commented on OSLCCORE-124:
---------------------------------------

POST with application/x-www-form-urlencoded content should be supported as this is a typical HTTP pattern.

> Query spec doesn't say whether POST with application/x-www-form-urlencoded should be supported
> ----------------------------------------------------------------------------------------------
>
>                 Key: OSLCCORE-124
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-124
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>          Components: Query
>            Reporter: David Honey
>            Assignee: James Amsden
>
> 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.
> http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up#Query_Capabilities says:
> "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:
> @RestMethod(
> 			name="POST",
> 			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.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]