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..
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.
..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.
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.
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.
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
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.