Research API client #687
Labels
No labels
_CRITICAL_
API
app
backEnd
Blocked, waiting for further changes
bug
cleanup
close
design
duplicate
enhancement
feature request
frontEnd
help wanted
invalid
low priority
needs input
needs review
project documentation
question
research
reviewed
script
security
SQL
style
testing
topLevel
wontfix
No milestone
No project
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Andras/BoundlessFlowCampus2K#687
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We need to implement a standard for how we should test and debug our APIs. After some basic research on my part i found the tool API client. I tested this technology using bruno and must agree it was a bit easier than using curl.
But now to the task: Should we even be using a API client. If this is the case which specific API client best suits our needs.
research API clientto Research API clientA API client will be very useful for testing as they are a third party application that can easily test different API calls and showcase the results of those calls without any direct integration into the project. This makes testing API calls easier and gives very detailed information.
This will make testing api's and using complex api's easier as we can easily call a API endpoint and receive results with clear explanations for data types, headers etc...
Bruno is a git native API client which means it can store its results in folders and text files that can be sent along with git pulls and pushes. So Bruno could be used to test Endpoints and API's, those results will be stored in a text file that will act as documentation of API calls/ url endpoints and their results which can help develop different views by giving clear documentation of existing endpoints and what data they receive.
Bruno also contains code generation where a specific endpoint or API call can be converted to code and be used in the react framework.
It is possible to take the bruno file, containing enpoints, and use it to create a mirror JS file that contains all those same endpoint. Creating a single file containing all urls that cards can get information from. But this is a lot of extra complicated work for very little gain as whenever changes are made in the bruno file, either from a new api or swapping out a api, those same changes need to be made in the mirror file. Creating unnecessary upkeep. The bruno file also uses its own language in the same style of the compose.yaml file which means its readable but brand new which can be hard to use especially if we want a specific element of that file.
I would suggest that we use Bruno as an API client to test and troubleshoot any and all API's but also as detailed documentation of all endpoints and the data contained in those endpoints making it easier for our develpores to know what endpoints they need to use for frontend components.
Good research overall and the explanation of why API clients improve testing and debugging is clear. The section about Bruno being git-native is especially useful and relevant for our project.
The parts explaining how Bruno can simplify endpoint testing, improve API documentation, and help frontend developers understand available endpoints were also well described.
Would maybe be good If we compared Bruno with some other Api clients.
Forgot to say this. I only compared Bruno to Postman but Postman is cloud based and does not have a free team version and is not git native so i stopped reasarching postman after that point. If therer are other Clients then i havent found any and if they are git native the size and popularity of Bruno sort of tells its own story i believe
We will probably chose Bruno but before this decision is made we are going to ask customer
Nothing needs to be done. I am going to close