Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undocumented Request API methods #213

Open
flaki opened this issue Mar 9, 2022 · 2 comments
Open

Undocumented Request API methods #213

flaki opened this issue Mar 9, 2022 · 2 comments
Assignees

Comments

@flaki
Copy link

flaki commented Mar 9, 2022

I noticed a couple inconsistencies between Runnable API and documentationthat I wanted to document below to allow for tracking and further discussions.

  1. There is a variety of set* methods in some languages (e.g. Rust) which are there to enable experimentation with runnables implementing some middleware-functionality. These are intentionally undocumented for now as the API ergonomy and usecases are developed.
  2. In JavaScript the body method returns a JS string. and the bodyBytes method needs to be used to get the raw bytes. Other runtime seem to default to body returning the raw bytes.
  3. The state method in every supported language seem to return the state key value as a string, JavaScript and some other languages also provide a "raw" method (state_raw or stateBytes) to get the raw bytes which is undocumented.
@flaki
Copy link
Author

flaki commented Mar 10, 2022

@ospencer could you have a look at 2./3. here and comment on whether they are intended or improving the consistency here would be useful / planned?

Particularly if 3.) is correct and raw bytes for state keys are useful, we should ensure this is also supported by all languages, not only JS/TS.

@ospencer
Copy link
Contributor

In JS, the result of an HTTP request is a custom HttpResponse class, with methods text() to get the body as a string, json() for JSON, and arrayBuffer() for an ArrayBuffer. It was done this way to feel the most idiomatic for JS... Consistency across languages is tough. Ideally, the API provided by Reactr's interface would be "good enough" for each language. I have lots of thoughts about this that we should probably schedule some time to chat through.

As for state, I don't think that access to the raw bytes is particularly useful, and we should maybe remove it and standardize across the languages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants