If we ask the right questions up front, we can prevent such a result. While this is more often the case than not, I’d consider it an edge case in API design. This is especially true in legacy APIs that accumulated more and more parameters over a decade or so, such that they no longer fit in the query string. Every endpoint uses POST and all parameters are in the body. The simplest way to add in all parameter data is to put everything in the body.
#Advanced host monitor restful api Patch#
There are many ways in HTTP to add parameters to our request: the query string, the body of POST, PUT and PATCH requests, and the header. That is, each request contains all of the information necessary for a connector to understand the request, independent of any requests that may have preceded it. Roy Fielding said this eloquently:Īll REST interactions are stateless.
Same goes with APIs, especially stateless ones like REST APIs. If the function doesn’t take any parameters, we can’t directly affect this return value. In a programming language, we can request a return value from a function. Generally speaking, parametrization is a kind of request configuration. While HTTP verbs and resource URLs allow for some basic interaction, oftentimes it’s necessary to provide additional functionality or else the system becomes too cumbersome to work with.Īn example of this is pagination: we can’t send every article to a client in one response if we have millions in our database.Ī way to get this done is with parametrization.
When we’re designing APIs the goal’s to give our users some amount of power over the service we provide.
0 kommentar(er)
