[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:all-tabpanel ]
David Honey updated OSLCCORE-124:
---------------------------------
Description:
The spec only mentions use of GET. However, 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.
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.
was:
The spec only mentions use of GET. However, 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.
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
> 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 spec only mentions use of GET. However, 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.
> 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]