Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft REST API Guidelines

github.com

Post reply on HN
Print view View original

11–20 of 149 posts

Re: Microsoft REST API Guidelines

#11

Post by SwellJoe »

danpalmer wrote: post #2

Being that guy again, (and sacrificing my karma) but... This is not REST, it contains nothing about hypermedia, entities having knowledge of their URIs, or any way of discovering features of an API programmatically. While I'm sure there's plenty of good stuff in here (it looks otherwise fairly comprehensive), APIs will continue to be a disparate system that requires custom code for every integration until we can embr…

REST seems like an elephant in a room with some blind folks. Everybody who touches it thinks it's something different than the next guy, and they're all describing only one element of the thing.

That said, I don't actually know what this elephant looks like, either, because everybody I've read on the subject seems to have only a partial understanding of it...thus, I have a partial understanding of it.

If you know what the whole elephant looks like, and have good resources for what makes something actually REST, I'd be interested.

Re: Microsoft REST API Guidelines

#12

Post by icebraining »

SwellJoe wrote: post #11
danpalmer wrote: post #2

Being that guy again, (and sacrificing my karma) but... This is not REST, it contains nothing about hypermedia, entities having knowledge of their URIs, or any way of discovering features of an API programmatically. While I'm sure there's plenty of good stuff in here (it looks otherwise fairly comprehensive), APIs will continue to be a disparate system that requires custom code for every integration until we can embr…

REST seems like an elephant in a room with some blind folks. Everybody who touches it thinks it's something different than the next guy, and they're all describing only one element of the thing. That said, I don't actually know what this elephant looks like, either, because everybody I've read on the subject seems to have only a partial understanding of it...thus, I have a partial understanding of it. If you know wha…

I suggest you go to the original source, ie, Roy Fielding:

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

http://roy.gbiv.com/untangled/tag/rest

https://www.infoq.com/articles/roy-fielding-on-versioning

Re: Microsoft REST API Guidelines

#15

Post by danpalmer »

SwellJoe wrote: post #11
danpalmer wrote: post #2

Being that guy again, (and sacrificing my karma) but... This is not REST, it contains nothing about hypermedia, entities having knowledge of their URIs, or any way of discovering features of an API programmatically. While I'm sure there's plenty of good stuff in here (it looks otherwise fairly comprehensive), APIs will continue to be a disparate system that requires custom code for every integration until we can embr…

REST seems like an elephant in a room with some blind folks. Everybody who touches it thinks it's something different than the next guy, and they're all describing only one element of the thing. That said, I don't actually know what this elephant looks like, either, because everybody I've read on the subject seems to have only a partial understanding of it...thus, I have a partial understanding of it. If you know wha…

This is the video that made it finally "click" for me. https://vimeo.com/20781278

We don't yet have the abstractions, libraries, conventions or standards for this to work fully yet, but we're close.

Re: Microsoft REST API Guidelines

#16

Post by ams6110 »

yeukhon wrote: post #4

https://evertpot.com/dropbox-post-api/ This discuss some option for the GET vs POST. In Kibana, everything is done over GET as get parameters, and I find that extremely annoying and a poor design. A lot of public APIs also don't honor or have any intentions in supporting or using PATCH. Most APIs I have worked with only use PUT for modification. Anything resembles "creation" is automatically a POST.

I have worked with some systems that do not expose all http methods. Having a fallback way to invoke a method as a GET or POST makes your API more usable to more clients.

Re: Microsoft REST API Guidelines

#17

Post by danpalmer »

rimantas wrote: post #9
danpalmer wrote: post #2

Being that guy again, (and sacrificing my karma) but... This is not REST, it contains nothing about hypermedia, entities having knowledge of their URIs, or any way of discovering features of an API programmatically. While I'm sure there's plenty of good stuff in here (it looks otherwise fairly comprehensive), APIs will continue to be a disparate system that requires custom code for every integration until we can embr…

Not sure about your karma sacrifice, but if someone has doubts: > What needs to be done to make the REST architectural style clear on the > notion that hypertext is a constraint? In other words, if the engine of > application state (and hence the API) is not being driven by hypertext, > then it cannot be RESTful and cannot be a REST API. Period. Is there > some broken manual somewhere that needs to be fixed? That's b…

Thank you for that quote, I shall save it for future use.

Also lots of replies and 0 points. That's what I'm talking about, this always gets downvoted.

Re: Microsoft REST API Guidelines

#18

Post by ianai »

SwellJoe wrote: post #11
danpalmer wrote: post #2

Being that guy again, (and sacrificing my karma) but... This is not REST, it contains nothing about hypermedia, entities having knowledge of their URIs, or any way of discovering features of an API programmatically. While I'm sure there's plenty of good stuff in here (it looks otherwise fairly comprehensive), APIs will continue to be a disparate system that requires custom code for every integration until we can embr…

REST seems like an elephant in a room with some blind folks. Everybody who touches it thinks it's something different than the next guy, and they're all describing only one element of the thing. That said, I don't actually know what this elephant looks like, either, because everybody I've read on the subject seems to have only a partial understanding of it...thus, I have a partial understanding of it. If you know wha…

I think the above commentor got it right. You map the CRUD actions to HTTP verbs and statuses, as many of them make sense for your API, with links to further resources along the way.

Re: Microsoft REST API Guidelines

#19

Post by danpalmer »

varenc wrote: post #7
danpalmer wrote: post #2

Being that guy again, (and sacrificing my karma) but... This is not REST, it contains nothing about hypermedia, entities having knowledge of their URIs, or any way of discovering features of an API programmatically. While I'm sure there's plenty of good stuff in here (it looks otherwise fairly comprehensive), APIs will continue to be a disparate system that requires custom code for every integration until we can embr…

I'm fine with APIs continuing to be disparate systems if they have a simple, sensible design and have comprehensive documentation. Let's just stop calling them "REST" since they're not as you've pointed out.

Why not push for them to become something more? Documentation for humans is good, but you know what's better? Documentation for computers so that we don't have to build integrations anymore!

Re: Microsoft REST API Guidelines

#20

Post by icebraining »

gregmac wrote: post #10
pstuart wrote: post #3

Earlier quoted context omitted.

Any shining examples you'd care to share?

Agreed, and specifically: > APIs will continue to be a disparate system that requires custom code for every integration until we can embrace the full benefits of REST Have an example of a client that DOESN'T require custom code to use an API? I think this entire debate is summed up best by: > There is no magical "smart client" that somehow knows that rel=comments means that the link leads to comments about the curren…

The thing is, those servers and clients already exist, people are just to tied to their notion of "API" to see them. And in fact, you used them to post that very comment.

A website is a RESTful service which a generic client can interact with despite not having any custom code. Does it do so by magically understanding what an or tags are or by magically decoding PNG bytestreams? No, the service uses standard formats that the browser knows and which encode these semantics, allowing it to process them despite its original developers quite possibly not even knowing that service existed.

Post reply on HN