HTTP GetRequest workflow
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 20/100
- Loại issue
- Tái cấu trúc
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- csharp
- Lĩnh vực
- api, networking
Hướng nghiên cứu
Bắt đầu bằng việc xem xét hai workflow được mô tả xoay quanh BH.Engine.HTTP.Compute.GetRequest(url), GetRequest và HTTPAdapter. So sánh các cách tiếp cận Adapter/Pull, implicit-adapter và Execute được đề xuất, bao gồm entry point BH.Adapter.HTTP.PullRequest(url) được đề xuất và các ảnh hưởng đối với UI. Công việc chỉ được xem là hoàn tất khi đã thống nhất workflow và thuật ngữ trước khi có thể xác định phạm vi triển khai.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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 -
- following the Adapter/Pull work flow
Feeding aGetRequestinto a Pull with also aHTTPAdapter - A simpler workflow mirroring the expression of a single http request string. Through
BH.Engine.HTTP.Compute.GetRequest(url)which directly returns thestringresponse
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.

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!?

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

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

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).

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...

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
- Ngôn ngữ chính
- C#
- Star
- 2
- Fork
- 1
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của BHoM/HTTP_Toolkit
-
Make this toolkit/adapter more versatile and available for ASP.NET/web tools.Có thể đã có người làm @Tom-Kingstone đã nhận 18 ngày trước. Đang mởtype:feature
BHoM/HTTP_Toolkit#134 · 1 bình luận · 1 người được giao ·
-
Upgrade project files to SDK-style format compatible with dotnetCó thể làm lại được @adecler đã nhận 221 ngày trước và không có pull request nào đang mở. Đang mởtype:compliance
BHoM/HTTP_Toolkit#123 · 1 người được giao ·
-
BatchRequest not working as expectedCó thể làm lại được @rolyhudson đã nhận 1829 ngày trước và không có pull request nào đang mở. Đang mởtype:bug
BHoM/HTTP_Toolkit#72 · 1 người được giao ·
-
HTTPConfig Support for Byte / String / Other Response Return typesCó thể làm lại được @epignatelli đã nhận 2248 ngày trước và không có pull request nào đang mở. Đang mởtype:feature
BHoM/HTTP_Toolkit#52 · 1 bình luận · 2 người được giao ·
-
The number of responses resulting in the Pull is not of the expected length when using BatchRequestCó thể làm lại được @epignatelli đã nhận 2571 ngày trước và không có pull request nào đang mở. Đang mởtype:bug
BHoM/HTTP_Toolkit#13 · 2 bình luận · 1 người được giao ·
Tất cả issue của BHoM/HTTP_Toolkit
Issue tương tự
-
area-System.Numerics.Tensors untriaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
dotnet/runtime#134691 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
ci-failure-cause test-failure
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
AvaloniaUI/Avalonia#22312 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100