11–20 of 192 posts
Apart from HTTP Basic Auth, but please don't use that.
I would like to add Microsoft's API Guidelines [1] here, which is also a well written document and can be helpful to anyone designing an API. [1]: https://github.com/Microsoft/api-guidelines/blob/master/Guid...
Seems pretty good. Specifically this part of the guide is pretty well written: https://cloud.google.com/apis/design/resources . One thing that is surprising to me however is that their is no mention of using HTTP Status Codes in responses.
I don't recall that specific scenarios, but over the past year I learned this with the maps API. As long as you're hitting a real endpoint, then it will return 200 - even when there are errors and it should clearly return a matching http status code.
I suppose it so the same API could be implemented in any given protocol, however, I don't think that is useful in many cases.
Step 1) document the endpoints enough that outside developers can write their own clients. It took quite a bit of work for me to get a native Clojure client working to connect to the google cloud SDK. That was after wrestling with jar-hell around gRPC and calling the Java client from clojure, which is decidedly not pretty.
E.g. for the GKE API: https://cloud.google.com/container-engine/reference/rest/
(For people that rather use an existing library, this lets you pick one of 7 languages and start from there: https://cloud.google.com/docs/ )
Please drop fixed headers from web pages. If you want easy access to the top of the page use anchor links instead. On a laptop headers often take a big chunk of available screen. It just pisses me off every time I see a page with a fixed header. All your reader aren't using imacs...
This is a marketing website. I'm sure they A/B tested the fixed header and it probably converts better than otherwise.
Seems pretty good. Specifically this part of the guide is pretty well written: https://cloud.google.com/apis/design/resources . One thing that is surprising to me however is that their is no mention of using HTTP Status Codes in responses.
Well, I can tell you from using their API's that Google doesn't necessarily use them. I don't recall that specific scenarios, but over the past year I learned this with the maps API. As long as you're hitting a real endpoint, then it will return 200 - even when there are errors and it should clearly return a matching http status code. I suppose it so the same API could be implemented in any given protocol, however, I…
Otherwise HTTP status codes for errors are used, and standardized internally.
My biggest pain when designing a rest API is a standard authentication method that won't drive me crazy. So far i've always used 3rd party modules to implement different kinds of authentication but I never quite understood it in depth. Apart from HTTP Basic Auth, but please don't use that.
My biggest pain when designing a rest API is a standard authentication method that won't drive me crazy. So far i've always used 3rd party modules to implement different kinds of authentication but I never quite understood it in depth. Apart from HTTP Basic Auth, but please don't use that.
What's wrong with basic auth with HTTPS? You can delegate authentication with OAUTH and then use OAUTH for authorization but authentication still has to be done somewhere.
My biggest pain when designing a rest API is a standard authentication method that won't drive me crazy. So far i've always used 3rd party modules to implement different kinds of authentication but I never quite understood it in depth. Apart from HTTP Basic Auth, but please don't use that.
> Apart from HTTP Basic Auth, but please don't use that. What's wrong with basic auth with HTTPS? You can delegate authentication with OAUTH and then use OAUTH for authorization but authentication still has to be done somewhere.
Also, the Protocol Buffers link in the 3rd paragraph is 404.