Specifications¶
What can you expect the client code to do and what not?
http Method |
|
|
|
|
|---|---|---|---|---|
parameter in |
||||
query string |
✔️ |
✔️ |
✔️ |
✔️ |
header |
✔️ |
✔️ |
✔️ |
✔️ |
body |
⛔ |
✔️ |
✔️ |
⛔ |
path |
✔️ |
✔️ |
✔️ |
✔️ |
formData |
⛔ |
☑️ |
☑️ |
☑️ |
⛔ not specified by the RFC ✔️ supported ☑️ possible but cross your fingers
Summary of the supported parameters and http-methods in this tool
Read |
Write |
Modify |
Delete |
|
|---|---|---|---|---|
SQL |
|
|
|
|
HTTP |
|
|
|
|
analogy between CRUD operations for SQL and RESTful Web API
Query Strings¶
Assign a dictionary to the fields_data argument to set the query
string. The key value pairs in the dictionary will be parsed to:
endpoint➕? ➕ key=value&key2=value2
path Parameters¶
Path parameters will be dropped into the URL using a f-string. If you require a specific format make sure you pass that path parameter as a string.
This is because currently the data-type of the parameter which in specified in swagger is not parsed .
Request Body¶
By default any content in the body will be encoded in JSON and the
Content-Type header will be set to application/json.
There is no object validation built in.
Using formData in the Body¶
If you do need to use formData you can do so by adding the following header:
Content-Type: application/x-www-url-encoded
This is the same as a query string but hidden in the body.
header¶
There is no restriction on behalf of this tool on what you do with the header. It is possible to send a custom header fields with any client class method
Two headers are set by default:
Content-Type : application/json
Accept : application/json
Additionally any Authorization header will appended.
Authorization : (Bearer) SomeFancyJwtTokenForExample