Implement 'paths' endpoints

[kevin-pease]

✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)

Fixes #53. Adds all endpoints of the paths endpoint group, thereby concluding the implementation of all endpoints.

Notes:

• tests were added only for creating requests, not for comparing expected Testnet results. The reason for this is that it is currently not possible for us to extract usable test results from the API.
• this branch was created anew and the code was transferred from another feature branch. This branch was corrupted due to (developer's) git complications, hence the terse commit history.

🤔 Checklist before submitting

• All projects build
• Follows style guide lines
• Relevant documentation was updated
• Rebased onto current main

[tluijken]

Ziet er goed uit "as always". Ik zou graag nog wat toevoegingen zien aan de tests.

1. Kunnen we de gemaakte requests uitvoegen op de horizon API? Ja, die gaan inderdaad geen resultaat opleveren, dus daaraan kunnen we niets checken. Maar er zijn bepaalde combinaties wel en niet mogelijk met dit endpoint. Ik wil eigenlijk borgen dat alleen die scenario's ondersteunen die een status 200 terug geven, en geen 400 (bad request).

Bijv: als ik alleen de 'required' inputs invul, krijg ik toch heen status code 400 terug.

Als ik alles in vul, krijg ik ook een 400:

{
  "type": "https://stellar.org/horizon-errors/bad_request",
  "title": "Bad Request",
  "status": 400,
  "detail": "The request requires either a list of source assets or a source account. Both fields cannot be present."
}

Er zijn dus een aantal combinaties die werken met die endpoint, en een aantal combinaties die niet werken. Die moeten we wel borgen.

Tevens zou ik het fijn vinden als we het response in ieder geval deserialiseren en valideren die de ListStrictRecievePaymentPaths terug geeft:

Dan weten we zeker dat onze modellen in ieder geval compatible zijn.

[kevin-pease]

Goede punten, die maar gelijk het belang van goede tests bevestigen. We kunnen inderdaad wat verder gaan met de tests. Ik heb wel een vraag:

Hoe maak je in je eerste scenario die request? De nieuwe Laboratory laat je niet eens verzenden zonder alle required fields in te vullen. Daar staat trouwens nadrukkelijk bij dat de source account required is. Waarom deze in jouw voorbeeld onder de optionele fields staat begrijp ik niet. Ik heb dit in ieder geval proberen te ondervangen door de struct met 3 generics te laten werken (corresponderend met de required fields). Zolang er een generic nog op de default waarde staat (dus bv NoSourceAccount) kan je de request nog niet meegeven aan de horizon client. Die heeft namelijk uitdrukkelijk DestinationAsset, DestinationAmount, SourceAccount in de argumenten staan (in het geval van de find payment paths). Ik dacht hierbij dus de kracht van Rust voor me te laten werken.

Het tweede scenario verbaast me. Ik heb dit niet teruggevonden in de documentatie en Laboratory. Dit is wederom waarom we dus testen :) Ik zal dit inderdaad gaan afdekken.

Wat betreft je laatste scenario snap ik niet helemaal wat je bedoelt; de methods in de horizon client returnen een PathsResponse, die overeenkomt met (volgens mij) de responses van alledrie de endpoints?

[tluijken]

Goede punten, die maar gelijk het belang van goede tests bevestigen. We kunnen inderdaad wat verder gaan met de tests. Ik heb wel een vraag:

Hoe maak je in je eerste scenario die request? De nieuwe Laboratory laat je niet eens verzenden zonder alle required fields in te vullen. Daar staat trouwens nadrukkelijk bij dat de source account required is. Waarom deze in jouw voorbeeld onder de optionele fields staat begrijp ik niet. Ik heb dit in ieder geval proberen te ondervangen door de struct met 3 generics te laten werken (corresponderend met de required fields). Zolang er een generic nog op de default waarde staat (dus bv NoSourceAccount) kan je de request nog niet meegeven aan de horizon client. Die heeft namelijk uitdrukkelijk DestinationAsset, DestinationAmount, SourceAccount in de argumenten staan (in het geval van de find payment paths). Ik dacht hierbij dus de kracht van Rust voor me te laten werken.

Het tweede scenario verbaast me. Ik heb dit niet teruggevonden in de documentatie en Laboratory. Dit is wederom waarom we dus testen :) Ik zal dit inderdaad gaan afdekken.

Wat betreft je laatste scenario snap ik niet helemaal wat je bedoelt; de methods in de horizon client returnen een PathsResponse, die overeenkomt met (volgens mij) de responses van alledrie de endpoints?

Ik roep het endpoint hier aan. Hier kan je rechts in je scherm de verplichte parameters invullen, en eventueel optionele parameters (die stiekem verplicht blijken in de juiste combinatie).

Hier haal ik ook de response vandaan. Als daar verwarring over is, omdat de modellen uit de laboratory niet overeen komen met deze output, dan kunnen we die eventueel laten zitten. Als het slechts naamgeving is, maar de content klopt met het model, dan kunnen we hier wel mee verder.

[tluijken]

Klein cosmetisch dingetje, verder echt top gedaan Kevin!

[tluijken]

Deze zie ik vaker voorbij komen. Wellicht mooier (en praktischer in onderhoud) om dit in de test module 1 keer te definieren en gerbruiken over alle tests.

[kevin-pease]

Ja, daar heb je een punt. Ik had dat bij een ander endpoint ook al een paar keer geprobeerd. Zodra er 1 waarde verandert in de testdatabase moet je 't alsnog uitelkaar trekken. Als dat preferabel is, dan doen we dat gewoon 😃