You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment we have these 7 methods to interact with the low-level API:
/** * Create and send a GET request. */publicfunction requestGet(string$path): bool;
/** * Create and send a POST request. */publicfunction requestPost(string$path, string$body): bool;
/** * Create and send a PUT request. */publicfunction requestPut(string$path, string$body): bool;
/** * Create and send a DELETE request. */publicfunction requestDelete(string$path): bool;
/** * Returns status code of the last response. */publicfunction getLastResponseStatusCode(): int;
/** * Returns content type of the last response. */publicfunction getLastResponseContentType(): string;
/** * Returns the body of the last response. */publicfunction getLastResponseBody(): string;
The first 4 methods will send a request to the server and save the response in the Client. The last 3 methods can now be used to get the response details. This has some downsides:
If we send multiple requests (like we do in the mid-level API AbstractApi::retrieveData()), only the latest response will be available in the client. This leads to possible race conditions: There is no way to guarantee, that the last response in Client really belongs to our request.
We have to call the client 3 times to retrieve all response data. This is a code smell and should be replaced with a small object.
Proposal
I propose to introduce a new Request containing the method, path, content type and body and a new Response interface, containing the status code, content type and body.
interface Request
{
/** * Returns the http method. */publicfunctiongetMethod(): string;
/** * Returns the path with optional attached query string. */publicfunctiongetPath(): string;
/** * Returns content type. */publicfunctiongetContentType(): string;
/** * Returns the body content. */publicfunctiongetContent(): string;
}
interface Response
{
/** * Returns status code. */publicfunctiongetStatusCode(): int;
/** * Returns content type. */publicfunctiongetContentType(): string;
/** * Returns the body content. */publicfunctiongetContent(): string;
}
The client methods could then simplified into one method.
Another point that I would like to improve is the "content type guessing" based on the path in the clients. In NativeCurlClient and Psr18Client we have the following code to determine the content type:
This method is very speculative and uncertain. The client should not make any assumptions about the request.
Instead we should add a way to provide the content type via the request() method. It makes sense to bundle the 4 parameters (method, path, content-type, content) in a simplified request interface that is compatible to PSR-7. I will update have updated the proposal.
Usage of the low-level API could then work like this:
At the moment we have these 7 methods to interact with the low-level API:
The first 4 methods will send a request to the server and save the response in the Client. The last 3 methods can now be used to get the response details. This has some downsides:
AbstractApi::retrieveData()
), only the latest response will be available in the client. This leads to possible race conditions: There is no way to guarantee, that the last response in Client really belongs to our request.Proposal
I propose to introduce a new
Request
containing the method, path, content type and body and a newResponse
interface, containing the status code, content type and body.The client methods could then simplified into one method.
The text was updated successfully, but these errors were encountered: