this post was submitted on 07 Jul 2023
805 points (99.9% liked)
Programmer Humor
32464 readers
436 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It's hard when you hit an endpoint that hits another endpoint, because technically the first request IS a 200. No right or wrong way as long as they are consistent and document it clearly imo
Now here is the fun part: they do not have a API documentation; they only have a very generic guide on how to setup webhook API
Microsoft code docs are the literal worst
Lmao, Microsoft code docs are absolutely amazing compared to the undocumented bullshit I have to deal with at most companies that have rolled their own services.
Shit, Microsoft docs are better than most other large companies with broadly used software even, not just random undocumented BS from smaller companies and products. In my experience, Microsoft's Xamarin docs are somehow often a better guide for Android development than Google's docs (good god are the official Android docs some of the hottest garbage that a company of Google's size and talent could put out), and I've yet to find a better general reference for any language or library than Microsoft's .NET documentation. I've seen a lot of people dunk on it for it's verbosity and/or "example bloat" but I love the length of their docs for breaking down different use-cases and giving examples of each, along with potential misuses and recommended alternatives.
That said, they do still have some garbage docs (like what OP is pointing out), but my general experience with their docs, especially for their larger/more mainstream products, has been surprisingly positive.
Right but Microsoft isn't most companies, it's a SOFTWARE company. A multibillion dollar one at that. Compared to other even multimillion dollar companies, their docs are fucking atrocious
Not my experience at all. What specific docs are you looking at?
Because the .NET documentation and their Azure documentation are some of the best docs I've used and come across. Azure's doc certainly kick the crap out of GCP and AWS.
Their azure documentation is mostly surface level. They make all those docs like they're talking to a user not a dev. They're limited AF when you're actually trying to deploy an app via a ci/cd pipeline
Microsoft365 docks have several articles that are fully depreciated and there is no disclaimer at the top about switching to new security standards or anything like that.
That's just off the top of my head, but there have been plenty more I've had the displeasure of using
Deploy to what? I've had no issues deploying to App Service from both Github actions and Azure pipelines and azure functions / static web apps were even easier.
Microsoft docs in general are the worst. Can't tell you how many fucking dead links and straight up incorrect information I've come across on their official help articles
Or deprecated documentation that has no indicator whatsoever that it's out of date
I see you've never dealt with chip vendors
Thankfully not
I my experience you then send a different error code to help developers know that right away. Really if there is nothing the developer could do it should be a 500 server error. The server did in fact error.
If the developer should have done something different then translate it to an appropriate code, 400 bad request or something
X-Forwarded?
Can / should you use it for anything other than IPs?
Well, if its acting as a proxy, then the status code should be transmitted intact right?
It's not really a proxy, it's just making another request as part of its request
In this case I like to return a 502.
Great time to implement a 7XX code: https://github.com/joho/7XX-rfc
739 might be a good one
Nice! I’m definitely going to implement 787 at work.