HttpApi, HTTP/GET method not exposed in swagger

develop · April 30, 2025, 11:31am

Hello,

I found out a strange thing - if I expose a method for REST interface in RODL library, using “HttpApiPath” attribute, the method will be published in OpenAPI/Swagger document only if it is called by HTTP methods POST, PUT, PATCH. If the method is marked for calling using HTTP/GET (attribute “HttpApiPath”), the method is not published in the swagger, so it cannot be debugged using tools like SoapUI, Postman… Nevertheless, calling such a method (HTTP/GET) via the REST/HttpApi is functional, it can be used.

Specifically, this is caused by the following code in the unit “uROHttpApiRODLConverter.pas”:

function TROHttpApiMethodInfo.Validate2: Boolean;
begin
  Result := not Assigned(fBodyParameter) or
               (Assigned(fBodyParameter) and
               (String2HttpApiMethod(fRequestMethod) in [hamPOST, hamPUT, hamPATCH]));
end;

Can you please enlighten me what the reason is? In the OpenAPI/Swagger specification, I did not find any mention of limiting method exposure to POST, PUT, PATCH calls only..

Thanks, regards from Prague.

Jiri

EvgenyK · April 30, 2025, 11:53am

Hi,

according to GET - HTTP | MDN :

The GET HTTP method requests a representation of the specified resource. Requests using GET should only be used to request data and shouldn’t contain a body.

from OpenAPI Specification - Version 3.1.0 | Swagger :

Can you provide example from OpenAPI/Swagger documentation that GET request has body parameters, pls ?

develop · April 30, 2025, 12:02pm

..according to this specification, an endpoint can be published/tagged using any HTTP/xxx operation, e.g. GET. The code in the RemObjects library only allows endpoint publication for POST, PUT, PATCH operations, no others.

This is what I was referring to..

EvgenyK · April 30, 2025, 12:07pm

Hi,

from OpenAPI Specification - Version 3.1.0 | Swagger

so

The requestBody is only supported in HTTP methods where the HTTP 1.1 specification RFC7231 has explicitly defined semantics for request bodies.

You can use other parameters (i.e. not body ones) for GET operations.

develop · April 30, 2025, 12:34pm

I’m not sure we understand each other on the substance of the problem. I believe that there is nothing preventing to publish methods with HTTP/GET operation in swagger, according to the specification, see:

I understand that “requestBody” cannot be used for GET operations, but that’s a slightly different topic, IMHO.

EvgenyK · April 30, 2025, 1:24pm

Hi,

from rest - HTTP GET with request body - Stack Overflow

Yes, you can send a request body with GET but it should not have any meaning. If you give it meaning by parsing it on the server and changing your response based on its contents, then you are ignoring this recommendation in the HTTP/1.1 spec, section 4.3:

…if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

And the description of the GET method in the HTTP/1.1 spec, section 9.3:

The GET method means retrieve whatever information ([…]) is identified by the Request-URI.

which states that the request-body is not part of the identification of the resource in a GET request, only the request URI.

Update

The RFC2616 referenced as “HTTP/1.1 spec” is now obsolete. In 2014 it was replaced by RFCs 7230-7237. Quote “the message-body SHOULD be ignored when handling the request” has been deleted. It’s now just “Request message framing is independent of method semantics, even if the method doesn’t define any use for a message body” The 2nd quote “The GET method means retrieve whatever information … is identified by the Request-URI” was deleted. - From a comment

From the HTTP 1.1 2014 Spec:

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

You will likely encounter problems if you ever try to take advantage of caching. Proxies are not going to look in the GET body to see if the parameters have an impact on the response.

develop · May 5, 2025, 8:45am

Hello,

I still don’t think we understand each other on the substance of the question. Let me try to rephrase it: how can we expose REST endpoints that are served by HTTP methods other than POST, PUT, PATCH? Am I to understand that the REST API, modeled in the RemObjects server, can (must) contain only endpoints with POST, PUT, PATCH methods and no others…? If so, the value of the “HttpApiPath” attribute in the RODL should be restricted and validated to these methods.

I will ask for an explanation, thank you.

Regards from Prague.

Jiri

EvgenyK · May 5, 2025, 9:32am

Hi,

Complex (aka body) parameters are supported only by POST, PUT, PATCH methods.

You can use Header/Query/Path parameters like

    [ROServiceMethod]
    [ROHttpAPIMethod('st', 'GET')]
    function method_get(
      [ROHttpAPIQueryParameter]
      a:Integer;
      [ROHttpAPIQueryParameter]
      b:Integer): Integer; virtual;

curl -v -X GET “http://localhost:8099/api/st?a=3&b=4” -H “accept: application/json”

Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying ::1:8099...
*   Trying 127.0.0.1:8099...
* Connected to localhost (127.0.0.1) port 8099 (#0)
> GET /api/st?a=3&b=4 HTTP/1.1
> Host: localhost:8099
> User-Agent: curl/7.72.0
> accept: application/json
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Accept-Encoding: gzip, identity
< Connection: keep-alive
< Content-Length: 1
<
7
* Connection #0 to host localhost left intact

    [ROServiceMethod]
    [ROHttpAPIMethod('sum/{a}/{b}', 'GET')]
    function method_get2(
      a:Integer;
      b:Integer): Integer; virtual;

curl -v -X GET “http://localhost:8099/api/sum/1/2” -H “accept: application/json”

Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying ::1:8099...
*   Trying 127.0.0.1:8099...
* Connected to localhost (127.0.0.1) port 8099 (#0)
> GET /api/sum/1/2 HTTP/1.1
> Host: localhost:8099
> User-Agent: curl/7.72.0
> accept: application/json
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Accept-Encoding: gzip, identity
< Connection: keep-alive
< Content-Length: 1
<
3
* Connection #0 to host localhost left intact

    [ROServiceMethod]
    [ROHttpAPIMethod('sum2', 'GET')]
    function method_get3(
      [ROHttpAPIHeaderParameter]
      a:Integer;
      [ROHttpAPIHeaderParameter]
      b:Integer): Integer; virtual;

curl -v -X GET “http://localhost:8099/api/sum2” -H “accept: application/json” -H “X-a: 4” -H “X-b: 2”

Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying ::1:8099...
*   Trying 127.0.0.1:8099...
* Connected to localhost (127.0.0.1) port 8099 (#0)
> GET /api/sum2 HTTP/1.1
> Host: localhost:8099
> User-Agent: curl/7.72.0
> accept: application/json
> X-a: 4
> X-b: 2
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Accept-Encoding: gzip, identity
< Connection: keep-alive
< Content-Length: 1
<
6
* Connection #0 to host localhost left intact