Replace http-types with http

[ntrinquier]

As mentioned in #1937, http-types is not being maintained (and neither are some its dependencies).

This replaces it with the http crate which seems to be the ecosystem standard (10x more recent downloads).

[github-actions]

Thank you for your contribution @ntrinquier! We will review the pull request and get back to you soon.

[ntrinquier]

@microsoft-github-policy-service agree company="Helsing"

[heaths]

This does get rid of a lot of older dependencies as well, since it seemed to pull in strict dependencies (probably using the older resolver; I never looked exactly). Might be worth it on that alone.

I'm still pondering on whether it's even worth it. Do we really need compatible types with other apps? Our generated clients are passing the right HTTP method. We do expose the StatusCode but could just as easily return our own. @ntrinquier is there any benefit to returning a common StatusCode in this case? I suppose I could see a web app "forwarding" the status on through their APIs, but we could always impl From common ones as well instead of actually returning someone else's. Sure, we still need a dependency in that case, could make it optional and, at the very least, not have our public API depend on someone else's type. That's how I'm leaning currently.

@analogrelay @LarryOsterman what do you think? To summarize, I'm leaning toward defining our own HTTP method enum (customers should never need to pass this anyway; it's public so our other crates can use it from azure_core) and defining our own StatusCode that can stay stable and we support From for http::StatusCode behind a feature flag (or not).

/cc @RickWinter @ronniegeraghty @JeffreyRichter

[heaths]

Thank you for your contribution! I'm leaning toward taking this, in part, but reconsidering whether we even should expose third-party StatusCode from our error and response types. After GA, we have pretty strict no-breaking changes policy, though it's good to see that http did declare a 1.x stable release so, as long as they stick to semver, we should be stable.

Still, the only reason we expose Method from azure_core is because other crates need it to call into client methods. It's not meant to be truly customer public. StatusCode obviously is, but we could just as easily return our own with, optionally, From impls to http::StatusCode...perhaps behind a feature flag so the dependency is optional (if not already transitive) by default.

We'll talk internally about our public API shape, but I'd love to hear if you can think of any good reason to expose Method other than just having to since we have separate crates.

[heaths]

Based on all the build errors, we need at least std.

[ntrinquier]

is there any benefit to returning a common StatusCode in this case?

I'd love to hear if you can think of any good reason to expose Method

Not really, I went with the straightforward implementation which is a drop-in replacement, and so it preserves the status quo.

I do not see a problem with defining our own types, and in fact I think it would be nice to hide the dependency behind a feature flag by default, because new major versions of ubiquitous dependencies like http are always difficult to pick up.

Could you let me know after you get the chance to discuss internally? Then I can finalize the PR based on your feedback and guidance!

[heaths]

because new major versions of ubiquitous dependencies like http are always difficult to pick up.

True; however, I did check and we already have transitive dependencies on http anyway, so putting any From<> impl behind a feature flag would be moot.

[ntrinquier]

@heaths just wanted to check whether you have some definitive guidance? :)

[heaths]

We're going to define our own StatusCode and probably Method as well. These are straight forward enough and given limited use, there's really no reason for a 3P dependency just for these. But I'm starting a major refactor of azure_core so I'll take the opportunity to define those as well.

[heaths]

Thanks for your work on this! Since we decided to define our own anyway, I started by copying - with attribution - the types from http_types we were already using. Makes for a smaller code change and I prefer enums for this purpose over constants anyway.

I opened #2331 which will replace this one.

[ntrinquier]

Thanks for your work on this! Since we decided to define our own anyway, I started by copying - with attribution - the types from http_types we were already using. Makes for a smaller code change and I prefer enums for this purpose over constants anyway.

I opened #2331 which will replace this one.

No worries, happy to see a decision has been made, and I will be looking forward to the other MR being merged!

[heaths]

...though, we may end up having to use constants anyway. I've made StatusCode an "extensible enum" and we're discussing it internally (open to feedback externally as well, of course!), but several of us agree the DX on constants is just...bad.