Hey SymbolicFrank,
Yes, and I did.
Ok, good, you handled the parameters, nice
The TFPHTTP client expects a server, a path and a file to get. For most modern sites the URL is a function to call and a set of parameters. 20 years ago that would have been totally fine. Today, not so much.
For the verb/method GET, most API sites need an endpoint, some sort of authentication and some parameters in some cases.
For the verbs/methods POST, PUT, DELETE, most API sites need an endpoint, some sort of authentication, some content on the
RequestBody and maybe some parameters.
- For the endpoint, it's the piece of the URL that comes after the site's domain and you put that on the URL string.
- For the verbs themselves, apart from GET and POST, depending on how the site gets the others, usually it's via a Header added to the RequestHeaders.
- For the authentication:
- if it's basic, you have Username and Password properties.
- if it's something else, you have the RequestHeaders and/or parameters. - For the RequestBody you have a stream type of thing, so you can put anything in there, even plain old JSON.
You usually then get JSON or XML as the result of calling one of the verbs/methods, so you can then process that elsewhere in your app.
From a modern perspective, I don't see what more you need in terms of added functionality to
TFPHTTPClient.
If so, and I guess I could've missed something, could you please be a bit more specific on what you feel is missing?
And I did add and fix it all.
You've lost me here again. What did you add and fix?
This is just my feedback on what definitely could (and probably should) be improved.
Ermm, again, pardon me for asking, but I don't recall you mentioning or specifying any improvements.
What I recall is you mentioning a lot of things that are either wrong or missing according to your opinion.
Cheers,
Gus