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

How Not to write a "REST" API

api.sharefile.com

Post reply on HN
Print view View original

11–20 of 117 posts

Re: How Not to write a "REST" API

#11

Post by Torn »

vyrotek wrote: post #6
lvillani wrote: post #5

Looks like an RPC-style API with multiple endpoints + custom authentication scheme.

I was going to mention this. If this documentation completely removed the word 'REST' would we have cringed as bad?

Probably not, but after seeing how nice REST API's can be with sensible url mappings, HATEOAS, HTTP methods as verbs, etc. it's almost insulting for sharefile to call it RESTful (presumably because it can return JSON?).

Off the top of my head:

- API method urls are all the same .aspx, regardless of method used

- All calls are sent as GET (ignoring the whole point of HTTP methods in REST)

- No HTTP method codes as responses for automated parsing

- Custom authentication putting credentials in URL or in headers instead of relying on proven HTTP auth schemes we've been using for years (basic, form, etc)

- Return format is done with get arguments instead of HTTP content negotiation in headers (not so bad)

They've completely missed the boat here.

Re: How Not to write a "REST" API

#13

Post by anty »

artanis0 wrote: post #9
adamjernst wrote: post #2

Yeesh. According to this chart: http://nordsc.com/ext/classification_of_http_based_apis.html Sharefile is not even a HTTP API (since it doesn't use HTTP methods correctly). For security purposes, authentication can be further increased by a POST of the "username" and "password" through the HTTP Headers as individual headers instead of the query string. POST https://subdomain.sharefile.com/rest/getAuthID.aspx HTTP/1.1…

As someone just starting to learn about secure restful web services: what is wrong with this security implementation of theirs?

Username and password are still sent in plain-text. You could use HTTPS to make the communication secure.

Re: How Not to write a "REST" API

#14

Post by lvillani »

vyrotek wrote: post #6
lvillani wrote: post #5

Looks like an RPC-style API with multiple endpoints + custom authentication scheme.

I was going to mention this. If this documentation completely removed the word 'REST' would we have cringed as bad?

I believe it's important to keep things honest. If an API is nowhere near the definition of being RESTful, then don't label it as such.

This company, along with others (e.g.: Flickr and their infamous "REST" API), are responsible for turning "REST" into yet another buzzword.

Re: How Not to write a "REST" API

#15

Post by alexchamberlain »

artanis0 wrote: post #9
adamjernst wrote: post #2

Yeesh. According to this chart: http://nordsc.com/ext/classification_of_http_based_apis.html Sharefile is not even a HTTP API (since it doesn't use HTTP methods correctly). For security purposes, authentication can be further increased by a POST of the "username" and "password" through the HTTP Headers as individual headers instead of the query string. POST https://subdomain.sharefile.com/rest/getAuthID.aspx HTTP/1.1…

As someone just starting to learn about secure restful web services: what is wrong with this security implementation of theirs?

It's not compliant with the HTTP standard.

Re: How Not to write a "REST" API

#16

Post by SomeOtherGuy2 »

anty wrote: post #13
artanis0 wrote: post #9

Earlier quoted context omitted.

As someone just starting to learn about secure restful web services: what is wrong with this security implementation of theirs?

Username and password are still sent in plain-text. You could use HTTPS to make the communication secure.

No they aren't sent plain-text:

>https://subdomain.sharefile.com/rest/getAuthID.aspx

Notice the https. The facepalm is just that there's no additional security in using POST vs GET.

Re: How Not to write a "REST" API

#17

Post by SomeOtherGuy2 »

alexchamberlain wrote: post #15
artanis0 wrote: post #9

Earlier quoted context omitted.

As someone just starting to learn about secure restful web services: what is wrong with this security implementation of theirs?

It's not compliant with the HTTP standard.

In what way is it not compliant?

Re: How Not to write a "REST" API

#18

Post by carbocation »

SomeOtherGuy2 wrote: post #16
anty wrote: post #13

Earlier quoted context omitted.

Username and password are still sent in plain-text. You could use HTTPS to make the communication secure.

No they aren't sent plain-text: > https://subdomain.sharefile.com/rest/getAuthID.aspx Notice the https. The facepalm is just that there's no additional security in using POST vs GET.

POSTed values won't show up in typical server logs, whereas with GET their plaintext password would normally be logged on every request.

And POST over HTTPS keeps the POSTed values hidden from those who might listen, whereas with GET over HTTP it would just be out there in the URL.

Re: How Not to write a "REST" API

#19

Post by euroclydon »

Torn wrote: post #11
vyrotek wrote: post #6

Earlier quoted context omitted.

I was going to mention this. If this documentation completely removed the word 'REST' would we have cringed as bad?

Probably not, but after seeing how nice REST API's can be with sensible url mappings, HATEOAS, HTTP methods as verbs, etc. it's almost insulting for sharefile to call it RESTful (presumably because it can return JSON?). Off the top of my head: - API method urls are all the same .aspx, regardless of method used - All calls are sent as GET (ignoring the whole point of HTTP methods in REST) - No HTTP method codes as res…

The query string and headers ARE encrypted in https. And forms auth, that's just a post and a cookie. You can't require API clients to support cookies.

Re: How Not to write a "REST" API

#20

Post by SomeOtherGuy2 »

carbocation wrote: post #18
SomeOtherGuy2 wrote: post #16

Earlier quoted context omitted.

No they aren't sent plain-text: > https://subdomain.sharefile.com/rest/getAuthID.aspx Notice the https. The facepalm is just that there's no additional security in using POST vs GET.

POSTed values won't show up in typical server logs, whereas with GET their plaintext password would normally be logged on every request. And POST over HTTPS keeps the POSTed values hidden from those who might listen, whereas with GET over HTTP it would just be out there in the URL.

You have no way of knowing what they log and don't log. If their server logs are compromised, you should be assuming their username/password database was as well.

And HTTPS requests are encrypted. The whole request, including the "GET /someurl&password=s33krit HTTP/1.1" part. As I said, using POST doesn't add any additional security to this.

Post reply on HN