WIP Produce the simplest-possible getting started guide for the Bisq HTTP API #54

cbeams · 2018-05-17T09:19:41Z

This PR is being created from a squashed version of @blabno's original commits in blabno:feature/http-api.

This is the first of what may become a collection of such guides designed to get new API users up and running as quickly as possible with working code that implements the simplest possible versions of real-world use cases.

@blabno

This is a squashed version of @blabno's original commits put together by @cbeams for the purposes of submitting it as a pull request.

cbeams · 2018-05-17T10:36:24Z

For posterity, here is the Slack conversation between @blabno and me (@cbeams) that led to this iteration of the doc. It describes the history and design motivations behind this kind of 'getting started guide' effort. From https://bisq.slack.com/archives/C75ABAU9J/p1526035993000053:

bernard [12:53 PM]
@cbeams is this the level of detail you would like to see https://github.com/blabno/bisq-docs/blob/feature/http-api/exchange/howto/http-api.adoc ?

cbeams [1:39 PM]
Thanks so much for posting this early-ish, @blabno. This looks like the beginning of what could be a good User Guide / User Manual sort of doc (as you refer to it above), but it’s different than what I have in mind when I talk about a “Getting Started Guide”.

Getting Started Guides are about providing step by step instructions to accomplish a specific use case that results in working code.

You can see how we did this at Spring by browsing through the Getting Started Guides at https://spring.io/guides. It’s good to look through the full list there, to get a sense of what I mean by specific use cases, but in particular, look at the “Getting Started building a RESTful Web Service” guide at https://spring.io/guides/gs/rest-service/.

We followed the same approach at Gradle, and again you can browse the available Getting Started guides at https://gradle.org/guides/.

Have a look in particular at https://guides.gradle.org/building-java-libraries/
Notice when comparing each of these guides, they all have a very similar structure. They are focused on a specific use case, they tell the user what they’re going to build, what they’re going to need, and then provide the simplest possible step by step instructions to fulfill accomplish that use case. They always end up with working code. And in case there’s any trouble, the end result of the code they should create in the step by step process is available as a standalone repository (it would be fine in our case if it were just a directory under the bisq-api repository).
This is similar to what we’re doing with the Getting Started with Bisq guide underway at #37

You can just jump to the current deploy preview at https://deploy-preview-45--bisq-docs.netlify.com/getting-started.html to have a direct look at the structure.
This guide is a little different than the Getting Started Guides I’ve called out above, because this one isn’t about writing code to accomplish a given task, it’s about following a set of steps to accomplish completing your first trade on Bisq,
but the principles are the same. The guide should be laser-focused on getting the reader from zero to hero. It’s a focused guide, not a general reference.
so it tells the user what they’re going to do, what they’re going to need, and then walks them step by step through exactly how to get that done.
Along the way, there’s plenty of room for sidebars that provide context and color,
but things should never digress into a general reference / User Manual style experience. The goal is to get the reader in and out as quickly as possible, wanting to come back for more.
the idea with these guides is that you write a lot of them.
Notice how there are very many of them in both the Gradle and Spring cases
So you can imagine that we would have similar guides for how to switch data directories, do backups, or whatever other use cases are worth documenting in this way with Bisq (none of that is clear yet… the only thing that’s clear is that we need at least one Getting Started with Bisq guide that focuses on completing the first, simplest possible use case of taking an existing offer), but we’ll see.
And it’s not obvious whether we’d want to have lots of guides around the API, but having at least one is a no-brainer for me. Something that shows the user, step by step, how to implement the simplest possible trading bot.
From there, the user will be hungry to come back for more,
they’ll be ready to consume more general purpose, reference-style documentation,
because they’ll have had a pleasant, guided, and ultimately successful experience getting everything set up for the first time.
Everything after that is easy by comparison, it’s all just tweaking stuff, it’s figuring out which other API calls are available, etc. And that’s where reference documentation is useful.
One other thing: please drop all the subdirectories, and just work on the file in the root directory of the bisq-docs repository. getting-started-http-api.adoc would be fine.
I started things off with the deeper directory structure you’re following suit with,
but as things have progressed, I’ve decided to keep everything flat, at least for now,
and to organize and group things “virtually” via the index.adoc file
I have a much larger outline / ToC for the docs site on its way,
but ultimately, we don’t know what directory structure (if any) is going to make sense in the end,
so I just want to keep everything flat.
Basically think of the whole site like a wiki that is evolving toward becoming a comprehensive Bisq Network operator’s manual.
And like (most) wikis, it has a flat namespace.
Allows for maximum flexibility in the future with structuring things,
and minimizes the need to do a lot of relative pathing when linking to other files.
One of the best things about focusing on Getting Started Guides like I’ve described them above is that it forces the team building the software to really put themselves in the shoes of those who are going to use the software. It forces you to think about things like “what is the most basic use case for the Bisq HTTP API?” “What is the simplest possible trading bot that could work?” “What are the bare minimum set of things the user will need and steps the user must take to actually build such a thing?”
I do not know the answers to any of these questions, and sometimes it is a judgment call. The very first guide we wrote for the Getting Started Guides effort on the Spring team was indeed the “Getting Started building a RESTful Web Service” guide you saw above, because at the time (2013), we were dead-certain that there were zillions of developers typing “how to build a RESTful web service with Spring” into Google. We wanted to write the definitive answer to that question, provide users with precisely what they needed, and shoot right to the top of the Google search rankings in the process. And that’s exactly what happened.
What we want to do here, is imagine, what is the Getting Started Guide that would provide the most value to someone who wants to start scripting their Bisq node to do automated trading? I’m already making an assumption here when I say that, i.e. that what people would want to do with this API is automate trading, as opposed to communicate manually with their Bisq node over a webapp or mobile app.
But I’m making that assumption, because I think that most people aren’t going to try to build bisq-mobile (like you are)—that’s a huge endeavor.
I think it’s reasonable to assume that a fairly large number of users would want to write a trading bot though,
indeed that’s the whole thing that got this effort going in the first place.

bernard [2:02 PM]
What I've described is complete trade flow which is a complete use case for Bisq I guess

cbeams [2:02 PM]
so what is the simplest possible trading bot? what language should it be written in to be a most effective demonstration? Java, Python?
there are tons of such decisions to make,
and while the resulting Getting Started Guide ends up being super lean, short and very quick and pleasant to follow, that’s only because the team who wrote it did the hard work and thinking to design a guide that would be relevant and as minimal as possible, etc.
As a reader, I wouldn’t think that what I’m supposed to do with that doc is follow it step by step, and, as it is now, I wouldn’t have any reason to believe that if I did follow every step, that I would end up with working code. I wouldn’t know that what I’m doing along the way is implementing a “complete trade flow”, because the doc never told me that’s what I’m going to do. I would look at that doc as something more like a collection of useful reference notes about how to do different things, but it wouldn’t be obvious to me that it’s a joined-up, step-by-step focused experience.
When I say simplest possible bot, I mean like the simplest possible bot:
e.g. a bot that listens for all incoming offers and prints out offers to sell BTC at less than a given distance from market price.
DEAD simple.
If I have to set up regtest, deal with arbitration, mess with docker, etc, I’m going to walk away
unless I’m super motivated.
If I follow a guide that ends up in me writing a super simple bot, and the whole thing takes me ~15 minutes,
I’m going to be effing thrilled
and hungry for more
I’ll be happy to take on more ambitious stuff,
because I have a base to build on
and a metal model of the project that I like

bernard [2:08 PM]
Ok, I'll create several tiny docs that allow user do to something on mainnet, so that they could do it out of the box

cbeams [2:08 PM]
and basically a positive emotional experience.
sure, one is enough to start with.
in my experience, these are deceptively difficult for people to write the first time around
making things simple is never easy
so I’d nail one down
and then move on to the next
don’t try to do several at once.
By the way, I’ll happily be the guinea pig to walk through that first doc. I’d really love to write my own trading bot for Bisq!
For this to really work, it’ll mean that I need to build your #bisq-desktop fork from source, because that’s the only one that will have the --httpApiEnabled flag available. This is fine, and you should definitely write the doc that way, i.e. with literally whatever steps are necessary to build a functional trading bot. When everything is ready for primetime and we integrate the http api into the canonical bisq-network/bisq-desktop repository, that step in the doc will go away, or get a lot simpler, of course. But in the meantime, if it actually spells out working instructions, that means that anyone can use the doc as soon as it’s written. We can start getting feedback on this stuff even before officially integrating it, which would be excellent.

bernard [2:16 PM]
Thank you for quick feedback Chris. I'll try to get it written ASAP

cbeams [2:16 PM]
Killer. Thank you.

bernard [2:18 PM]
Yes, that was another part that was making the writing hard. I want sure how the instructions should be cause I was writing it with integration in mind. I'll write it against current bisq-api code

cbeams [2:19 PM]
Yeah, just write it according to whatever I literally must do right now to get up and running. Then the doc should get simpler over time as more stuff gets integrated, etc.
Feel free, by the way to fully steal the format from the Spring and Gradle guides.
They are nearly identical in structure for a reason 🙂

See https://asciidoctor.org/docs/user-manual/#applying-source-highlighting

i.e. join artificially separated lines into a single line representing an entire paragraph. This approach is maximally conducive to effective editing and review, especially where `git diff --word-diff` is used (as seen in the output of diffs in the GitHub web UI).

Previously, the instructions would spin up an API instance that would attempt to use the default app name and app data directory, meaning that it would run into filesystem locks with an existing local Bisq app if one is running. We should assume that users interested in using the Bisq HTTP API are already running Bisq locally, and in order to avoid this kind of collision, and also to just generally play it safe, we should instruct the user to spin up their instance in a throwaway data directory. I've used the name 'bisqmon' here as in, a "Bisq monitor bot". This commit does *not* update the `docker run` invocation in the same way, but it should be updated to match.

Previously, the user was instructed to verify the API is up and running with the 'offers' endpoint and was then instructed in the next section to invoke the same endpoint. This change makes it easy to see that the API is up and running by returning a much shorter and easier to read response, and has the added side benefit of informing the user which version of Bisq they're running. The user then moves on in the next step to explore the 'offers' endpoint, which they're now more ready to do.

cbeams

NACK. This is already getting close to the mark, @blabno. I got excited walking through this guide myself. As I read and worked through it with my 'new user' hat on, I started to get a sense of the power that this API could afford me, and the possibilities started spinning. Good stuff. We can make it even tighter now, so that it's virtually all signal, no noise, gets the reader in and out quickly with working code at the end, and hungry to do more afterward.

You'll see I've done a fair bit of editing already in my review commits. Please do go through each one, read the commit comment and study the diff so we can align on common practices, style, etc.

I've left a number of review comments below as well, with checkboxes for convenience.

Thanks. I'm stoked about getting this out there for people. And what's great about the way we're doing it is that we can publish this doc literally as soon as this editing process is finished. We don't need to integrate anything into the canonical bisq-* repositories, etc. We can get it out there for people to allow them to try this stuff out right now, with minimum fuss, such that they can provide provide maximum feedback before we attempt to roll it all up into Bisq proper.

cbeams · 2018-05-17T12:23:13Z

http-api-monitor-offers.adoc

@@ -0,0 +1,327 @@
+= Monitoring Bisq offers with Http API
+
+This guide walks you through the process of creating a bot that monitors available offers and sends email notifications.


I'd like to drop the email notifications. It makes sense for a script you'd actually want to run in real life, but here in a "let's build the simplest possible bot that could actually work for the purposes of getting our heads around the Bisq HTTP API" guide, all the stuff around GMail and email libraries and usernames and passwords and the code required to bootstrap it all is just noise and makes the whole thing longer and more complicated than it needs to be. As I walked through this guide myself, I punted when I got to this point; I just didn't want to deal. Because: (a) I never use my GMail account, (b) it's set up for 2FA anyway so a simple username / password won't work, (c) I don't want to set up a test account just for the purposes of this guide that told me it would take 15 minutes and is now in fact going to suck up more of my time than I want it to.

As an alternative, just print interesting offers (i.e. those that match the filter) to the command line whenever they show up, or if for some reason that is not idiomatic, then to a file that the user can tail.

cbeams · 2018-05-17T12:25:29Z

http-api-monitor-offers.adoc

+}
+----
+
+Where `offers` is an array with individual offers and `total` is number of all offers. The model for each individual `OfferDetail` is defined as follows:


I'm not sure there's a lot of value in including the whole model here. As a reader, I feel like I'm supposed to do something with this, when in fact it's just for informational purposes. As an alternative, I'd deep-link the user to the swagger API docs that show this same information, and possibly do it in an INFO admonition so that the reader understands this is "just if they care / want to go deeper", and that it's not part of the critical path of the step-by-step guide.

This is problematic cause the link looks like http://localhost:8080/swagger#/offers/find3. That find3 might change into something else if we modify the resource in future by adding/removing GET endpoints.

cbeams · 2018-05-17T12:28:43Z

http-api-monitor-offers.adoc

+    direction: 'SELL',
+    paymentMethodId: 'SEPA'
+}
+----


This result and the "we need to filter those offers" language above again make me as a reader feel like I'm supposed to do something with this information. There is actually no "step" here, it's just for informational / context purposes, and that's fine, but it should be made more clear. For example, you can say something like:

We'll need to filter our offers using the static criteria you see below:

[json snippet]

In the sections that follow, we'll do just that with a combination of data returned from Bisq HTTP API endpoint calls and programmatic filtering.

(Very quickly written, but you get the idea)

List available offers and Get the market price parts are just describing how the API looks like.
I wanted to first give API overview and then dive into the javascript.

I've introduced API overview section and those List available offers and Get the market price are now subsections so it should be clear for the user that they don't need to do anything there.

cbeams · 2018-05-17T12:30:05Z

http-api-monitor-offers.adoc

+}
+----
+
+== The JavaScript part


I'd retitle this as something like "Write the monitoring bot code" or "Build the monitoring bot".

"The JavaScript part" sounds boring or like some random detail, whereas "Writing the bot" sounds like what I came here to do.

cbeams · 2018-05-17T12:36:12Z

http-api-monitor-offers.adoc

+
+    npm install lodash http-as-promised nodemailer
+
+In general our script will look like this:


In the sections that follow, I recommend that all source code snippets:

get sourced from an actual, e.g. 'bisqmon.js' source file checked into the repository. Or perhaps http-api-monitor-offers.js to align with the naming of this file. We'll probably need to think more about how to structure companion sources along with these docs in a flat namespace, but it doesn't matter much at this point: what does matter is that the code below should get extracted as snippets from real source code that actually works. Asciidoctor has great tools to help here, see https://asciidoctor.org/docs/user-manual/#include-partial.

get labeled such that they show the name of the file they're coming from (it's fine if all three are labeled as coming from the same file. The point is that this guide needs to be an extremely literal, step-by-step process of going from zero to working code. So if there is code that the user should write, you should tell them where to write it (i.e. in a file named bisqmon.js) and in which order to write it. Add this statement, add this function, and that function, and you're done.

cbeams · 2018-05-17T12:41:19Z

http-api-monitor-offers.adoc

+    0.25 BTC (-6%)
+
+[NOTE]
+If you would like to use something else that gmail then you will need a bit different mail transport configuration. For reference look at https://nodemailer.com/smtp/.


Can be dropped once email is gone.

Deliver a proper ending to the guide. Right now the ending is a bit abrupt. Wrap things up with a bit of prose (a 'congratulations' is fine), and I often like to do a "next steps" section at this point, where you can direct users to whatever other resources you think they may find most valuable after having just gotten started here. Of course this would include other HTTP API docs and guides as we write them, but it could also include encouraging users to come talk with the team in Slack, to provide feedback on the project via GitHub issues, etc.

cbeams · 2018-05-17T12:43:21Z

index.adoc

@@ -3,6 +3,7 @@
 * *_User Docs_*
 ** <<intro#, Introduction>> — What Bisq is, why it exists and how it works
 ** <<getting-started#, Getting Started>> — Go from zero to trading in 15 minutes
+ ** <<http-api#, Getting Started - HTTP API>> — How to access Bisq programatically


Should be updated to link to actual doc path, and should be titled something more like "Getting Started with the Bisq HTTP API" (especially so long as this is the only entry in this list. If it uses the actual title of the doc as it currently exists here ("Monitoring Bisq offers with Http API"), then it will seem too specific, and readers won't know that they should "START HERE" if they're new to the HTTP API.

cbeams · 2018-05-17T12:47:42Z

http-api-monitor-offers.adoc

+* NodeJS 6+
+* Docker (to run from an image) or Git and Maven (to build from source)
+* A GMail account
+


Right about here we should do an INFO admonition that lets the user know that the Bisq HTTP API is currently incubating, and that this means things may be a bit rough around the edges, that their feedback is extra appreciated, along with pointers about how to provide that feedback. You may just direct them to the "next steps" section at bottom where they can find out more about providing feedback (see my related comment about 'next steps' below).

cbeams · 2018-05-17T12:48:37Z

http-api-monitor-offers.adoc

+    cd bisq-api
+    mvn compile exec:java \
+        -Dexec.mainClass="io.bisq.api.app.ApiMain" \
+        -Dexec.args="--appName=bisqmon"


As I mentioned in 24ffd06, the --appName option and arg should be carried over to the docker arrangement as well. I have not done that in my edits.

cbeams · 2018-05-17T12:57:30Z

http-api-monitor-offers.adoc

+    mvn compile exec:java \
+        -Dexec.mainClass="io.bisq.api.app.ApiMain" \
+        -Dexec.args="--appName=bisqmon"
+


Right about here we should do an INFO admonition that explains why they're having to run a separate instance of Bisq to experiment with the HTTP API. It's going to be confusing as hell for users who have a perfectly good Bisq client already up and running locally to spin up a different, unrelated instance, unless they have that explained to them. I'd just explain it very clearly in the context of this being an "incubating" project, and that when the the project comes out of incubation, this functionality will be integrated directly into the official Bisq client you run locally. In the meantime, you need to spin up a separate instance to experiment with (and provide feedback on!) this incubating project.

cbeams · 2018-05-22T16:45:41Z

@blabno, I've pushed your commit 911f6ca to the PR branch, and I've also invited you as a collaborator on my fork so you can push any additional commits too. Could you go through my review comments above, check any / all boxes you've addressed and comment on anything that remains outstanding? I've taken a quick look at the changes, and they look good. I'll have more time to get back to this soon. Thanks.

blabno · 2018-05-23T07:14:10Z

Being collaborator on your fork @cbeams won't allow me to tick boxes in this PR made against bisq-network's repo.

cbeams · 2018-05-27T14:11:20Z

I see a few additional commits above, @blabno, thanks. Thanks too for noting "done" everywhere you've already addressed stuff. I'll go through this step by step myself once more with an eye toward merging and publishing it. If there's anything else you'd like to get in or wrap up before that happens, please go ahead.

cbeams · 2018-06-29T07:24:35Z

@blabno, I've just brought this PR up to date with the latest on master and made a few additional tweaks you can see in the commits above.

@m52go, would you be up for reviewing this doc? I believe we're close to being ready to ship and promote this, but I'd like to have someone else review it first, follow the instructions step by step and provide feedback on anything that trips you up. Of course you're free to suggest improvements to the text as well. I'm granting you collaborator rights on my fork so you can just push additional commits as you like.

In any case, the doc should take 15 minutes or so to read and complete from scratch. Even if all you can do is play the role of the uninitiated reader and provide your feedback, that would be very helpful.

m52go · 2018-06-29T15:21:21Z

@cbeams sure thing, will do within the next day or two.

More substantial suggestions to be posted in comments on GitHub.

m52go

My commit included copy edits and other minor changes. These are more substantive suggestions.

Overall it was very quick and easy...I think it took me less than 15 minutes! Very exciting stuff.

m52go · 2018-06-30T14:35:58Z

http-api-monitor-offers.adoc

+----
+
+[NOTE]
+Complete interactive API documentation is available at http://localhost:8080/swagger.


I'd make this stand out a bit more. I don't know if it was just me, but I glazed over it the first few times I saw it. (I also wasn't aware of Swagger, so I just thought it was a cool pathname).

Maybe take it out of a NOTE and make it something like "*Complete API documentation is available at http://localhost:8080/swagger*. It's interactive, so you can play around with it right in your browser."

m52go · 2018-06-30T14:37:24Z

http-api-monitor-offers.adoc

+** Docker (to run from an image) or
+** Git, Maven and JDK8 (to build from source)
+
+NOTE: Using the Bisq HTTP API in no way requires the use of NodeJS on the client side. It is just used for example purposes in this guide.


I suggest removing the parenthetical note above ("to execute the API client script...") and making this note more detailed.

Specifically, explicitly state:

Node.js is not a dependency of the HTTP API.

It's only used here to make the tasks of making HTTP requests and manipulating responses easier for the purposes of this example, but that those tasks can be done with any tools the user prefers.

m52go · 2018-06-30T14:44:26Z

http-api-monitor-offers.adoc

+}
+----
+
+Next we need to filter those offers by price. There are two types of offers: _market-based price offers_ and _fixed price offers_. They are distinguished by the `useMarketBasedPrice` attribute. In the case of market-based price offers the filtering criteria is easy: the `marketPriceMargin` value must be above 0.1. In the case of fixed price offers we have to fetch the market price of BTC in EUR, calculate whether the price is 1% or less, and then filter offers which have a price _less_ than that calculated price.


"On Bisq, there are two types of offers..." [Suggestion]

"In the case of fixed price offers we have to fetch the market price of BTC in EUR, calculate a threshold price that fits our needs (i.e., the price that's 1% lower than the market price), and then find all offers which have a price less than that threshold price." [Suggestion—I found this wording confusing]

m52go · 2018-06-30T14:59:55Z

http-api-monitor-offers.adoc

+include::http-api-monitor-offers.js[tags=flow]
+----
+
+So first 2 things to do (concurrently and asynchronously) is to fetch offers and market price of BTC from our API. Then we need to filter those offers and display the results.


Not sure "(concurrently and asynchronously)" adds any value.

m52go · 2018-06-30T15:06:35Z

http-api-monitor-offers.adoc

+
+Let's install some dependencies:
+
+    npm install lodash http-as-promised


Might be helpful to mention adding the require() statements here too.

I built the script as I read along, and ended up with errors because I didn't require() those modules. It's a super-simple thing that most people will figure out quickly, and I know it's already in the full script at the bottom, but just a quick mention along the lines of "don't forget to require these modules" or something might be nice.

m52go · 2018-06-30T15:15:22Z

http-api-monitor-offers.adoc

+
+=== Run the API using Docker
+
+The easiest way to run the API in headless mode is by using a Docker image:


Could 'headless' be clarified here? Knowing virtually nothing about how this API works, my initial impression was that the API would query my local Bisq client for data, and that 'headless' simply meant 'no GUI' but that's clearly not the case.

Basically I wasn't sure if the API needed my Bisq client to be running in the background.

A quick 1 or 2 lines about what these images actually do / how the API works might help?

Also, how does one know when the Docker image is done setting up? Is it when the Bisq ASCII art shows? I watched the terminal for a while until I realized that what I was seeing was actually streaming data, and API calls were already working.

m52go · 2018-06-30T15:18:31Z

http-api-monitor-offers.js

+}
+//end::getOffers[]
+
+function notify(offers) {


Aside from the require() statements, this notify() method was the one other item that wasn't mentioned in the text that I didn't have in my code when I ran the script for the first time.

Just FYI. I guess it's because this is structured as a bottom-up walk-through. If it were reversed (i.e., top-down approach with full script first and then important parts clarified), it would be fine to pick and choose what to cover.

m52go · 2018-06-30T15:19:29Z

http-api-monitor-offers.adoc

+
+== What you'll build
+
+You'll build a NodeJS-based script that connects to Bisq over an HTTP API to get offers and market prices and then displays "interesting" offers on the console if any are found.


I think it's officially 'Node.js'. Just concerned the JS hipster 'ninjas' will get us if we don't get this right...

cbeams · 2018-07-05T06:11:22Z

Thanks so much for the review and review commits, @m52go.

@blabno, back to you, thanks.

m52go · 2020-08-18T11:24:17Z

Closing as stalled since this API effort was superceded by another one.

Add 'Monitoring Bisq offers with the Bisq HTTP API'

95a2f88

This is a squashed version of @blabno's original commits put together by @cbeams for the purposes of submitting it as a pull request.

cbeams assigned blabno May 17, 2018

cbeams added 7 commits May 17, 2018 12:37

Apply source highlighting

e778141

See https://asciidoctor.org/docs/user-manual/#applying-source-highlighting

Remove unnecessary blank lines

70ce251

Render literal text with backticks where appropriate

7ee80ee

Edit for grammar, style and clarity

ae5b54a

cbeams commented May 17, 2018

View reviewed changes

Apply cbeams comments

911f6ca

Add note about appName parameter.

17a48d1

blabno force-pushed the http-api-monitor branch from b7b3ce8 to 17a48d1 Compare May 23, 2018 07:57

Bernard Labno added 2 commits May 23, 2018 10:05

Cleanup json snippets

d73a565

Add JDK and JavaFX to requirements section.

b73db83

This was referenced May 30, 2018

For May 2018 bisq-network/compensation#74

Closed

Bisq Docs Maintainer bisq-network/roles#29

Closed

Integrate HTTP API to bisq-network bisq-network/proposals#22

Closed

cbeams added 3 commits June 29, 2018 09:10

Merge branch 'master' into http-api-monitor

10be120

Remove now-global attributes from header

7d8e78c

Refine text, headings and admonitions

7eb1466

cbeams force-pushed the http-api-monitor branch from c289c35 to 7eb1466 Compare June 29, 2018 07:11

cbeams requested a review from m52go June 29, 2018 07:24

cbeams mentioned this pull request Jun 30, 2018

For June 2018 bisq-network/compensation#89

Closed

6 tasks

Implement basic copy edits

56d3185

More substantial suggestions to be posted in comments on GitHub.

m52go reviewed Jun 30, 2018

View reviewed changes

m52go mentioned this pull request Jul 31, 2018

For July 2018 bisq-network/compensation#103

Closed

ManfredKarrer changed the title ~~Produce the simplest-possible getting started guide for the Bisq HTTP API~~ WIP Produce the simplest-possible getting started guide for the Bisq HTTP API Mar 2, 2019

m52go closed this Aug 18, 2020

		@@ -0,0 +1,327 @@
		= Monitoring Bisq offers with Http API

		This guide walks you through the process of creating a bot that monitors available offers and sends email notifications.


		npm install lodash http-as-promised nodemailer

		In general our script will look like this:


		Let's install some dependencies:

		npm install lodash http-as-promised


		=== Run the API using Docker

		The easiest way to run the API in headless mode is by using a Docker image:


		== What you'll build

		You'll build a NodeJS-based script that connects to Bisq over an HTTP API to get offers and market prices and then displays "interesting" offers on the console if any are found.

WIP Produce the simplest-possible getting started guide for the Bisq HTTP API #54

WIP Produce the simplest-possible getting started guide for the Bisq HTTP API #54

Conversation

cbeams commented May 17, 2018

cbeams commented May 17, 2018

cbeams left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cbeams May 17, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cbeams May 17, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cbeams May 17, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cbeams commented May 22, 2018

blabno commented May 23, 2018

cbeams commented May 27, 2018

cbeams commented Jun 29, 2018

m52go commented Jun 29, 2018

m52go left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

m52go Jun 30, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

m52go Jun 30, 2018 • edited Loading

Choose a reason for hiding this comment

m52go Jun 30, 2018 • edited Loading

Choose a reason for hiding this comment

m52go Jun 30, 2018 • edited Loading

Choose a reason for hiding this comment

m52go Jun 30, 2018 • edited Loading

Choose a reason for hiding this comment

cbeams commented Jul 5, 2018

m52go commented Aug 18, 2020

cbeams May 17, 2018 •

edited

Loading

cbeams May 17, 2018 •

edited

Loading

cbeams May 17, 2018 •

edited

Loading

m52go Jun 30, 2018 •

edited

Loading

m52go Jun 30, 2018 •

edited

Loading

m52go Jun 30, 2018 •

edited

Loading

m52go Jun 30, 2018 •

edited

Loading

m52go Jun 30, 2018 •

edited

Loading