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

81–90 of 149 posts

Re: Microsoft REST API Guidelines

#81

Post by andybak »

mythz wrote: post #53
bunderbunder wrote: post #45

Earlier quoted context omitted.

Microsoft came up with OData about 10 years ago, but it's now steered by a technical committee with a lot of participants. I wouldn't necessarily be so quick to assume that the OASIS committee - or Microsoft's representatives on it - speak for all of Microsoft. Let alone an internal guidelines committee that they apparently convened fairly recently (given the age of the report) when they use that slogan.

This isn't just some poorly labelled content from a 10 year old legacy website from a time before they knew any better, the OData website got a recent redesign sporting new Stock photos and even larger font for their disingenuous labeling which still continue to push OData crapware under the REST banner to fool devs/CIO's into thinking if they adopt OData they're taking advantage of the best form of REST - which is i…

I recently had the misfortune to have to tackle oData to talk to Dynamics CRM. The choice was between that and SOAP so it was the lesser of two evils.

But compared to the other nice, modern REST API's I'm used it smelt of mould and enterprisey cobwebs. I'd have preferred an old school RPC API over that. At least API's that abuse REST from that direction tend to have the virtue of simplicity.

Re: Microsoft REST API Guidelines

#82

Post by ranyefet »

gedy wrote: post #51
blakeyrat wrote: post #41

I'd love to see some guidance on how you're supposed to do file uploads (think: uploading an image avatar for a user) and fit it into the REST structure. These guidelines don't even mention "x-www-form-urlencoded" except in a bit of fluff about CORS. Made more frustrating by Microsoft's own WebAPI2 basically having zero support for file uploads, meaning we had to go way outside the library to code support for it. Not…

POST /users/{id}/avatar ? What additional guidance would you expect?

You can turn the uploaded image into base64 string in the client and then just post it as part of your JSON payload.

Re: Microsoft REST API Guidelines

#85

Post by [deleted] »

jcrites wrote: post #72
vfaronov wrote: post #43

Earlier quoted context omitted.

Are you suggesting that Fielding did not intend REST to be used in automated systems? By "distributed hypermedia systems", did he really mean "alternative browsers for alternative WWWs"?

I can't adequately convey what I think is Fielding's position on how machines should interact with RESTful systems, but I will convey my understanding of the purpose and intent of his thesis: REST is a characterization of the Web architecture itself . It's not an alternative WWW, it is an abstract description of the principles behind the WWW. You can see this theme in Chapter 4 of the thesis in which Fielding charact…

[deleted]

Re: Microsoft REST API Guidelines

#86

Post by ferentchak »

dwightgunning wrote: post #74
ChrisAtWork wrote: post #70

Earlier quoted context omitted.

"Success With Info" is something that just causes problems. The number of examples we found of "Success with Info" going horribly wrong was abundant. Turns out checking return codes is something people have failed to do pretty much since the invention of the return code...

Is that a failure of the people or failure of the spec?

I think in many ways it's just tradition. Old browsers did wonky stuff with non 200 codes and that just created inertia that made people never quite take the effort to follow the spec.

Re: Microsoft REST API Guidelines

#87

Post by foota »

niftich wrote: post #77
foota wrote: post #75

Earlier quoted context omitted.

Returning just an array from a json-endpoint that may contain sensitive data is a vulnerability: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-js... (edit: may be mitigated in newer browsers)

The obvious mitigation is don't visit untrusted endpoints from your API client, and/or don't run a script interpreter inside your API client.

That's not what the vulnerability is here. If you have a server endpoint that returns an array without wrapping it as a property on an object then an attacker can write a webpage that overrides the Array prototype and requests the json from your page as a script, thereby bypassing the cross origin check it would be subject to as an xhr request. So if you have a page which returns sensitive information as an array you (were, it seems browsers probably don't allow you to override the array prototype anymore) are vulnerable to the attacker stealing a signed in users secrets.

Re: Microsoft REST API Guidelines

#88

Post by draw_down »

deathanatos wrote: post #26

Pagination is one of those things I feel like so many of these things get wrong. LIMIT/OFFSET (or as MS likes to call it, TOP/SEEK) style results in O(n²) operations; an automated tool trying to pull the entirety of a large collection in such a scenario is not good. I have to again recommend the excellent "Pagination done the Right Way" presentation[1] from Use the Index, Luke (an equally excellent site). Just return…

> while this removes the ability to of the client to go to an arbitrary page on its own

Yeah, that's the whole problem with this approach.

Re: Microsoft REST API Guidelines

#89

Post by niftich »

foota wrote: post #87
niftich wrote: post #77

Earlier quoted context omitted.

The obvious mitigation is don't visit untrusted endpoints from your API client, and/or don't run a script interpreter inside your API client.

That's not what the vulnerability is here. If you have a server endpoint that returns an array without wrapping it as a property on an object then an attacker can write a webpage that overrides the Array prototype and requests the json from your page as a script, thereby bypassing the cross origin check it would be subject to as an xhr request. So if you have a page which returns sensitive information as an array you…

On the contrary, that's precisely the vulnerability:

1. The API server needs authentication, which gets cached in the user-agent.

2. The same user-agent, with the same authentication context, is then directed to a malicious site.

3. The user-agent contains a javascript interpreter, and the malicious website serves a script to override the Array prototype.

4. The same script then executes a CSRF request to the API server, reusing the cached authentication context, and therefore stealing the response.

A browser fits all the necessary conditions that must exist for this vulnerability to be exploited, but if you're the consumer of the API, you don't have to use a browser as your user-agent. You can write your own, which you'd do if you're making these requests programmatically in a non-web application.

Regardless as to which user-agent you use, a viable mitigation is to not visit untrusted endpoints with the same cookie jar or authentication context.

Another viable mitigation is to omit including a script interpreter in your custom API client. This is in fact usually the case.

Re: Microsoft REST API Guidelines

#90

Post by Avernar »

JimDabell wrote: post #39
vfaronov wrote: post #31

Earlier quoted context omitted.

The big problem with using the hypertext Web as an example of REST is that there is a human operator literally driving that "engine of application state". Most API clients cannot afford to compute their state transitions on a network of 80 billion neurons.

No there isn't, a great deal of the web is loaded without direct human requests. For example: * Web crawlers * Archival services * Embedded resources (stylesheets, JavaScript, images) * Newsfeeds

All those examples are hard coded algorithms in the bulk copy category. They pretty much just use the GET method to download all or a specific subset of a site.

To truly drive a REST API requires a human or an AI. The AI doesn't need to be human equivalent, just smart enough to inteligently interpret the hypermedia. If the API changes the AI would be able to adapt.

I'm talking about the complexity of the computer on the Enterprise in ST:TNG. You give it a command and it figures out how to go about solving it.

Post reply on HN