Needs a 'help' link for dummies, right after each heading

[nilslindemann]

... which links to a short explanation how to use the API. For example:

All Lichess API request urls have the format:

https://lichess.org<path parameters><query parameters>

For example (without the newlines and without any other whitespaces in between):

https://lichess.org
/api/games/user/{username}
?max=1

The first part is always necessary.

The second part are the path parameters, always seen top right in the black area, side to side with the current chapter heading. Curly brackets ({ and }) indicate variables, aka locations where you insert concrete text (without the curly brackets). For example in the above example your real Lichess username, for example /api/games/user/DrNykterstein .

The third part (optional) are the query parameters. They start with the character ?. Each query parameter consists of a key, then the character = and then a value. For example max=1 in the above example. More than one query parameters are joined together using the character &. For example ?max=1&analyzed=true.

Here is an example Python 3 script for Windows, which downloads your most recent game (using the third party requests module), saves it to a file lastgame.pgn , and then opens that file with the software which on your operating system is responsible for opening PGN files.

# open_last_game.pyw

import requests
from pathlib import Path
from subprocess import Popen

username = 'Here_goes_your_username'
saveto = Path('C:/Lichess/lastgame.pgn')
saveto.resolve().touch()

game = requests.get('https://lichess.org/api/games/user/' + username + '?max=1')
saveto.write_bytes(game.content)

Popen(
    [str(saveto)],
    shell=True
)

[niklasf]

It's rust a normal REST API. I don't think every API reference has to teach absolute beginners. Perhaps add a single reference in the introduction.

[Dboingue]

It's rust a normal REST API. I don't think every API reference has to teach absolute beginners. Perhaps add a single reference in the introduction.

Is there even one example that does not rely on a full rounded application setting. Could there be a an example with more than one request and response dialgo. I think a jupiter notebook, with its cell modularity.. might be able to get the extra mileage across the dev to non-dev API interest gap in communication. The installers for jupiter would do all the micromagment req. installations behind the scene, and would have its own python... and then one could displa without all the formal application programming overhead barrier of learning potential.

I just tried again (almost once a year I keep trying to demystify across that gap). I would be in need of at least one such example that is touching authorization fog of mine. I am not proposing to produce myself such interactive trace myself. But I could build and progressively learn from such. It would not require much thinking in the other people shoes added effort I would think. All the things one takes for obvious.

I see with this closed issue, here, that I am not the only with similar discomfort about the overhead implied context or dev. context behind all the examples proposed. I see no interactive session example.. There are probably obvious things internalized when experienced in web tech, that one might not even realize constitute a barrier. I have dealt with API in the past, and I could navigate this one. but some conceptual relations around permssions and request versus answer actually input output supports... I started reading some readmes on the example. they all have some thing I find missing. It say put this file under this name.. And it is clear that there is a context assumed.. So instead of banging one's expert head on the wall to guess what a non-expert might bump silly into.

use easy platforms that reduce all the shop things that any web tech daily coder would have without even remembering that have set up. It is difficult to think across specialization. I think I am actually having a good suggestion. I did read that one can talk to the API with python.. I think that could work. I have no concept or RUST and across web handshakes and intermediate things or local browser space (i may have their existence, but I would get bogged down very fast in the details of pointing to it in some code). I hope this finds you, in spite of being a closed issue. Salutations.

did i miss something like I am suggesting? I would be nice instead of doing it like you say for all items.. to do it for a complex enough feature thouching a bit of all the possible hurdles specific to web communicatino and key interactions.. a complete loop of external engine creation, addition, listing, delteing with minimal number of engine examples.. I bet many people might be able to do that, not me.. But from such a low level entry barrier as I propose. I could generalize pretty fast.. and be able to adapt to any part of the API (I speak from experience in non web coding for science projects. It seems that the rust get post auth. web specific complexities are a barrier to me.. and I suspect others. I might even help once I get it myself. to create diagrams for the non string enclined readers (for concepts that are networky intrinsically for example). that need concept pictures that I bet you might have, not even realizing it. (hypothesis).

clue: "it is just normal rest". I don't know where this issue author is coming from. and it talking for his own needs of having some insight into other audience coming in, but I think this is still an issue. maybe not the initial suggestion. but the problem behind. sorry for the long babble. I hope enough redudancy through it for reducing amount of obligatory mistunderstanding across technical language barriers.