Let\'s assume a service offers some funcionality that I can use like this:
GET /service/function?param1=value1¶m2=value2
Is it righ
In REST, each HTTP verbs has its place and meaning.
For example,
GET is to get the 'resource(s)' that is pointed to in the URL.
POST is to instructure the backend to 'create' a resource of the 'type' pointed to in the URL. You can supplement the POST operation with parameters or additional data in the body of the POST call.
In you case, since you are interested in 'getting' the info using query, thus it should be a GET operation instead of a POST operation.
This wiki may help to further clarify things.
Hope this help!
It is nice that REST brings meaning to HTTP verbs (as they defined) but I prefer to agree with Scott Peal.
Here is also item from WIKI's extended explanation on POST request:
There are times when HTTP GET is less suitable even for data retrieval. An example of this is when a great deal of data would need to be specified in the URL. Browsers and web servers can have limits on the length of the URL that they will handle without truncation or error. Percent-encoding of reserved characters in URLs and query strings can significantly increase their length, and while Apache HTTP Server can handle up to 4,000 characters in a URL,[5] Microsoft Internet Explorer is limited to 2,048 characters in any URL.[6] Equally, HTTP GET should not be used where sensitive information, such as user names and passwords, have to be submitted along with other data for the request to complete. Even if HTTPS is used, preventing the data from being intercepted in transit, the browser history and the web server's logs will likely contain the full URL in plaintext, which may be exposed if either system is hacked. In these cases, HTTP POST should be used.[7]
I could only suggest to REST team to consider more secure use of HTTP protocol to avoid making consumers struggle with non-secure "good practice".