docs(weave): Upload and document Service API notebook

[J2-D2-3PO]

Description

https://wandb.atlassian.net/browse/DOCS-1050

• Edits and uploads Service API notebook created by @m-rgba
• Documents the notebook for MD generation
• Adds generated MD as new guide
• Adjusts generated MD a bit for cosmetics

Before merge, need to address failing GH check #3170 (comment)

Testing

• @J2-D2-3PO ran through the notebook to verify that code works / outputs for documentation
• @m-rgba verifies that the documented version retains / captures original meaning and content

[circle-job-mirror]

Preview this PR with FeatureBee: https://beta.wandb.ai/?betaVersion=02ebde2c0e27f71cca898a4f332128b42f1de87d

[J2-D2-3PO]

@wandb/weave-team help with a GH check requested please:

• Issue: test/Python lint (push) failing on ruff-format even after fix and commit. I don't think it's an issue from upstream since branch updates don't fix anything, and prbly isn't flake since it doesn't fix with reruns

• Fix attempt:

  It doesn't appear that I have the option to rerun the check from the UI either.

  1. Ran ruff check locally and got this output:

  notebooks/weave_via_service_api.ipynb:cell 5:1:1: I001 [*] Import block is un-sorted or un-formatted
  |
  1 | / import datetime
  2 | | import json
  3 | | import requests
  4 | | 
  5 | | # Headers and URLs
  | |_^ I001
  6 |   headers = {"Content-Type": "application/json"}
  7 |   url_start = "https://trace.wandb.ai/call/start"
  |
  = help: Organize imports
  
  Found 1 error.
  [*] 1 fixable with the `--fix` option.
  

  2. Ran ruff check notebooks/weave_via_service_api.ipynb --fix locally and recommitted in fe6fe58

[andrewtruong]

We have a first-party trace_server_interface for this -- curious why you're using the raw HTTP endpoint instead of that?

[J2-D2-3PO]

The initial code was created by @m-rgba - maybe they can provide that context? I just documented the code as it was. @andrewtruong do you think it would be promoting an anti pattern by using the raw endpoint? If so, I can go back in and update the notebook to use trace_server_interface?

[m-rgba]

Hey @andrewtruong - so when I initially created it:

• I made them while I was making a OpenWebUI plugin and didn't want the user to have to install any packages.
• Customer asked for some examples using the REST API since they were having trouble with the client.

My argument for why I feel like this could be valuable:

1. It's a good escape-hatch for anyone running where they can't use our client, or are having trouble with our client, but they want to send us traces.
2. The service API is the most language neutral method for sending us traces.

If either of these are true, our current OpenAPI docs get the user like 95% there - but are pretty easy to flesh out parts like - what's the shape of a completion we're expecting, or how should they format token counts.

100% open to this being an anti-pattern though, if we're updating the API or other reasons.
We could also do both, where we can have examples for manually creating traces with the client as well.

[andrewtruong]

For python we should recommend the first-party stuff, and for other languages we can recommend this HTTP approach.

That said, I'm not against it. We can still show python using the service API