Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

HTTP GetRequest workflow

未关闭
  • 哪里不对？
#20 5 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
20/100
Issue 类型
重构
描述清晰度
需要澄清
活跃度
停滞
技术栈
csharp
领域
api, networking

调研方向

首先审查围绕 BH.Engine.HTTP.Compute.GetRequest(url)、GetRequest 和 HTTPAdapter 描述的两种工作流。比较提议的 Adapter/Pull、隐式适配器和 Execute 方法，包括建议的入口点 BH.Adapter.HTTP.PullRequest(url) 以及对 UI 的影响。在确定实现范围之前，需要先就工作流和术语达成一致，之后才算完成。

由索引模型根据 Issue 内容生成。

描述

severity:low type:compliance type:question

Have been playing with the OpenStreetMap_Toolkit leveraging the HTTP_Toolkit 😍 😍 😍
(@rolyhudson)

Did lead to some thoughts around potentially consolidating the http requests to more clearly align with other areas of the BHoM. A few notes for comment - @epignatelli @alelom picking up from our chat earlier. Low priority and great to enable these experiments as some thinking needed I think to create a satisfactorily slick, consistent and clear work flow.

There are currently two implementations of HTTP requests -

  1. following the Adapter/Pull work flow
    Feeding a GetRequest into a Pull with also a HTTPAdapter
  2. A simpler workflow mirroring the expression of a single http request string. Through
    BH.Engine.HTTP.Compute.GetRequest(url) which directly returns the string response

The 2. above is neat - but needs to move out of Engine Compute as is externally interfacing.

The challenge we have is that a traditionally formatted http request contains the domain (i.e. source or adapter in BHoM terms) actually embedded in line with the request itself.
Our standard adapter Pull and Push workflows have naturally separated these concepts out.

Useful to align terminology and concepts where we can - but also be intuitive and respect conventions of the software/platforms we are adapting to.

The main comment I discussed with @epignatelli was to ensure clarity that a link (or adapter) with the outside world to BHoM is still being made. Even if not a standard Adapter -> Pull

So few options:

a)
This has redundant information for http as described above.
image

b)
Could separate out domain and rest of request arguments for the http string - but I think this is unintuitive if already familiar with performing http requests. Others opinions here are welcome - but feels we are forcing too hard into BHoM format!?
image

c)
Could allow not specifying adapter - where is implicit from the request?
image

d)
Could then enable implicit casting of correctly such that work flow might allow
image

e)
An option that might make sense is to achieve very close to the original BH.Engine.HTTP.Compute.GetRequest(url) , respecting the current exception of http, but migrating it to an Adapter NameSpace such that we could have something like BH.Adpater.HTTP.PullRequest(url).
image
This would not currently reflect into UI - so considerations needed there.

f)
Another final option would be that we do this as an extension of the Execute...

image

With this option I think we come close to some of the ideas we had before, where we considered implementing Executes with the actual Adapter not needing to be explicitly defined as additional input - being implicit in the Method you were executing.
This came up originally from discussions about executing external Python scripts etc.
Wonder if this might be a way forward?

Sorry for long notes - wanted to capture thoughts and discussions.
Perhaps one to pick up over a call?

@epignatelli @alelom @adecler @rolyhudson

主要语言
C#
星标
2
派生
1
平均合并
5 天 8 小时
30 天内合并 PR
2

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

BHoM/HTTP_Toolkit 的其他 Issue

查看 BHoM/HTTP_Toolkit 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。