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

Documentation #72

Open
SchlenkR opened this issue Oct 5, 2021 · 17 comments
Open

Documentation #72

SchlenkR opened this issue Oct 5, 2021 · 17 comments
Assignees

Comments

@SchlenkR
Copy link
Member

SchlenkR commented Oct 5, 2021

  • Multipart
@SchlenkR SchlenkR self-assigned this Oct 5, 2021
@varora-aga
Copy link

Hello,

I am a web developer working in ASP.net applications but have never worked in F#.
Searching out document editing capabilities remotely, I found Webdav and FsHTTP as alternatives.

I was able to successfully build the project and dont know how to use it.
Can you please let me know if you have any detailed document about configuration and deployment in IIS?

I didn't know a place to communicate so posting comment on this issue item.

Thanks,
Varun

@SchlenkR
Copy link
Member Author

FsHttp is no alternative to Asp.Net or any other content hosting / server side web framework. It’s a HTTP client library, that allows for sending HTTP requests to a web service.

@varora-aga
Copy link

Thanks for clarification.

I was working with MS Support guy and he recommended to go through this link and found FSHTTP reference there.
https://stackoverflow.com/questions/37276654/edit-in-word-using-wopi-and-office-online-server

Thanks.

Thanks,
Varun

@SchlenkR
Copy link
Member Author

SchlenkR commented Dec 13, 2021

I doubt that the answer intentionally referenced FsHttp. Maybe it was a mistake and „sftp“ instead of „FsHttp“ was meant?

@FlippievanDyk
Copy link

I have only just started making use of the library, and the lack of multipart documentation lead to me almost dropping it. I assumed it simply wasn't supported.

Excited to give it a go, think I'll be making use of source as a reference, unless you have made a start on some branch?

This library is fantastic, thank you for all the effort!

@SchlenkR
Copy link
Member Author

That would be really great, @FlippievanDyk - and thank you for the feedback. The documentation is something that definitely needs to be improved.

Here are some thoughts and hints:

  • I ask myself if the structure of the documentation is too fine grained. Maybe it's better to merge some topics - what do you think?
  • The current docu fucusses on explaining the DslCE style, but I find myself more often using the normal DSL style (also due to better intellisense support). As a first step for improvements, that's fine. In future releases, there might come some improvements for API of DSL style, too. Maybe it would be a good idea to provide examples in both styles side-by-side in the future (where it makes sense)?
  • There are several docu TODOs in several places in the repo. They could be collected and evaluated if they still make sense or not, and work them out.

HowTo: Edit and build the documentation

  • Editing: The source files for the docu are here
  • Building: In the repo's root, use: dotnet fsi .\build.fsx docu

I really appreciate your help, and you can write here or DM me any time. Thank you very much!

@FlippievanDyk
Copy link

FlippievanDyk commented Jan 12, 2022

I've taken a closer look at the docs now, and I have a few thoughts on what could be done.

First two questions.

  • It appears dotnet fsi .\build.fsx docu doesn't work. It only cleans the project. It doesn't make a difference Windows or WSL... running ./docu.ps1 does build the docs.
  • The files in the reference sub-directory: I assume auto-generated, is that from the code? I am not so familiar with documentation tooling.
  • And if they are auto generated, shouldn't the HTML files be removed and put in the .gitignore?

Then on to your hints:

  • I ask myself if the structure of the documentation is too fine grained. Maybe it's better to merge some topics - what do you think?

I think I tend to agree with this statement. For example, there are separate get, get with cache-control and a post with a body. These could conceivably have been one, with a more detailed explanation. Perhaps it would be appropriate to have a general example, even if conceited, too show as much in one spot, with an explanation.

That could then be followed with a section for adding header, adding body, adding multipart form.

  • The current docu fucusses on explaining the DslCE style, but I find myself more often using the normal DSL style (also due to better intellisense support). As a first step for improvements, that's fine. In future releases, there might come some improvements for API of DSL style, too. Maybe it would be a good idea to provide examples in both styles side-by-side in the future (where it makes sense)?

Again, I tend to agree. I have not used the Dsl style at all (partly due to lack of documentation, and I was slightly rushed). I think adding better docs for the DSL style would help. If you have working snippets, I would love to see one, just to show me in the right direction. Played around a bit just now, I think I understand it... Basically a fluent style?

  • There are several docu TODOs in several places in the repo. They could be collected and evaluated if they still make sense or not, and work them out.

I have seen a TODO or two, but I must honest I've only skimmed the docs back to front, I haven't read everything yet. I think you are better qualified than I to say what is still relevant there.

What I've done so far:

I've only added this small section in Making Requests

(**
Here is an example of a POST with a multipart form:
*)
 
 http {
    POST "https://reqres.in/api/fileUplod"
    multipart
    filePart "proofOfPayment.pdf"
  }

I am not sure really where to document it more fully... I see in #86 that the Full APi reference is broken. Linking to that from where Header, Body and Multipart are explained would help a lot I think.

@SchlenkR
Copy link
Member Author

SchlenkR commented Jan 18, 2022

For this library, my feeling is that having good examples should be the essential thing for a good documentation, since most of the used concepts are easy to understand. So let's focus on good examples.

To keep things simple, the current docu could be reworked:

  • Extend it with more use case examples.
  • Make important things like MultiPart and Configuration to appear more prominent using sub menu entries
  • Restructuring

Structure
Here is a proposal for the structure of the docu with some comments:

  • "Getting Started"
    The current "Making Requests" section could be the starting point for this topic. Put / move some simple examples here to show how the lib works for some common request / response use cases. It's the 80% one usually needs to know.
  • "Request Body"
    • json / text / stream / setting ContentType explicitly
    • formUrlEncoded
    • File Upload
    • Multipart (see tests)
  • Sending (async, lazy, etc.)
  • Response Handling
    Add some expect and assert examples (see: Response.fs, l. 125ff)
  • Configuration
    For each config method, there could be a simple example that explains the behaviour.
    • Basic configurations
    • HttpClient and HttpMessage
  • F# Interactive
    Add % operator (see: Operators.fs) - which should only be recommended for FSI usage
  • Advanced contepts
    • Builder types
    • Pre-configuring Builders
    • Naming Conventions
    • dispose behaviour somewhere

Hints

  • The tests are a source to look at for important use cases.
  • Alternative Styles: To keep things simple, the docu could be based on DslCE style for now, and an additional section explains alternatives:
http {
    POST "https://reqres.in/api/users"
    CacheControl "no-cache"
    body
}

post "https://reqres.in/api/users" {
    CacheControl "no-cache"
    body
}

Http.post "https://reqres.in/api/users"
|> Header.cacheControl "no-cache"
|> Request.send
|> Response.toJson

@FlippievanDyk
Copy link

I'm sorry I have taken so long to respond, had a bunch on my plate after hours, so haven't had a real chance to look at this.

I should have time this weekend to at least make a start. Anything I say further now won't be well thought out, so I'll rather not. Just wanted to let you know I haven't forgotten

@SchlenkR
Copy link
Member Author

There's no need for making pressure; you can always decide ad hoc what / if you want to do something - that's no problem... I also started with some smaller docu things, but didn't commit them yet. I try to commit them this evening and comment here and let you know :)

@SchlenkR
Copy link
Member Author

FYI @FlippievanDyk I just pushed my latest docu changes.

@nodakai
Copy link

nodakai commented Apr 5, 2022

Just wanted to confirm... the docs at https://fsprojects.github.io/FsHttp/ describe the upcoming v9 release (that's what I understood from https://fsprojects.github.io/FsHttp/08_Migrations.html ) whereas the latest at NuGet is 8.0.1? What might be the best way to learn how to use the latest NuGet 8.0.1? To read Migrations.html "backwards"?

@SchlenkR
Copy link
Member Author

SchlenkR commented Apr 5, 2022

Thanks @nodakai - I'll release v9 this evening. I thought having it released much earlier - so sorry for not having made a feature branch.

@nodakai
Copy link

nodakai commented Apr 5, 2022

Oh no need to apologize, thank you for all your efforts! I hope I can contribute a few paragraphs to the doc after I play with the v9 release

@SchlenkR
Copy link
Member Author

SchlenkR commented Apr 5, 2022

9.0.1 is released, and also an updated docu (which is far from complete as usual). Please give it a try - feedback appreciated!

@SchlenkR
Copy link
Member Author

see #101

@SchlenkR
Copy link
Member Author

Clarify this in the docu:

https://fsharp.slack.com/archives/C1R558VK7/p1653141311336839

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

No branches or pull requests

4 participants