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

91–100 of 117 posts

Re: How Not to write a "REST" API

#91

Post by tptacek »

SomeOtherGuy2 wrote: post #89
tptacek wrote: post #81

Earlier quoted context omitted.

I don't understand the point you're trying to make here, or the stridency with which you're making it. You in fact do know that the most popular web servers do log the URL, and do not log POST parameters or individual headers. That's why professional security audits will ding you for putting anything sensitive in a URL.

Actually, we ding you for putting sensitive information in URLs that are used in a browser. The reason is that it will then be sent to other sites in the referrer header. When it is used for an API it doesn't matter. A security audit will check that logs are not logging sensitive information or that they are properly secured and encrypted if they do contain such information. The combination of telling users to put th…

No, SomeOtherGuy. This is an HTTPS site. The referer header does not behave the way you're implying it does on HTTPS sites.

And having read and written this particular audit line item about 29074894389734897 times in the last 15 years, let me assure you that logging is clearly an issue.

The bit about how "if someone can see your logs you're already boned" is also message-board-logic more than reality. Logs are shipped all over the place. On a network pentest, one of the things you do when you pop a box is hunt for logs; even after you get root on the machine, you don't automatically have all the passwords that get stuck in the log files. Same goes for all the random LogLogic-style consoles those logs get fed to.

If you have more questions about this stuff, my contact info is in my profile --- just click my username above this comment. I just wanted to chime in to say that 'carbocation was exactly right, but my comments are now repeating themselves, and so I'm done on this thread.

Re: How Not to write a "REST" API

#94

Post by lysol »

tlack wrote: post #26

We're so spoiled that now we're complaining about the APIs we do get? I would have died for stuff like this ten years ago when using data from other sites involved scraping, harassment, and trickery. Just like not everyone can produce a beautiful, accessible, standards compliant website, not everyone can produce a perfectly REST API. I give them kudos for opening up their system, or at least attempting to.

Kudos for the API, but lying about it being REST can cost developers significant time or at least blow estimates. If they butcher their API this badly, would you really put stock in the backend being written in any kind of sane fashion? Would you trust it?

Re: How Not to write a "REST" API

#95

Post by ww520 »

Seeing their API just reminds me something. What is a good way to deal with methods that don't fit in the usual HTTP verbs (GET/POST/PUT/DELETE), like Rename, Grant, Revoke in their case?

In the past I've simply extended the uri to indicate additional methods like, POST /user/foobar/grant. I wonder whether putting those methods as additional HTTP verbs would be better.

Edit: extending HTTP verbs might not work too well with some firewalls/NAT that filter out non-standard verb requests.

Re: How Not to write a "REST" API

#96

Post by bryanh »

eli wrote: post #83
bryanh wrote: post #40

Earlier quoted context omitted.

Poignant observation. I'm currently working with an unnamed credit API and all calls, regardless of status, return 200. Options can be strung together in single GET parameter. All calls resolve to a single URL and the method is chosen get a GET param (which variant of that method is yet another param). And a person's information can be passed in via any slew GET params, or as POST'd XML. Its a mess... anyone up for a…

I once spent weeks writing a wrapper for a particular service provider's API (which they charge a premium to access). Every request was a POST and every response was 200. In one function, timestamps were represented by a unix epoch, but others had the same field encoded as ISO 8601. The XML returned was not guaranteed to be well formed. Etc. The kicker is that they declined permission to open source my wrapper becaus…

Sounds familiar. I wonder if the same masochistic fools wrote them both...

Re: How Not to write a "REST" API

#97

Post by alexchamberlain »

SomeOtherGuy2 wrote: post #88
alexchamberlain wrote: post #82

Earlier quoted context omitted.

It isn't compliant, it doesn't use the verbs properly.

Would you care to point out where in the HTTP RFCs it requires the use of certain methods for certain operations? The reality is, you can do whatever you like as far as HTTP is concerned. In fact, only GET and HEAD are required to be implemented, all the other methods are optional. HTTP does not have "verbs". That is REST. Just because they aren't using a REST API, doesn't mean they are not HTTP compliant.

RFC 2616

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Re: How Not to write a "REST" API

#98

Post by spacemanaki »

SomeOtherGuy2 wrote: post #88
alexchamberlain wrote: post #82

Earlier quoted context omitted.

It isn't compliant, it doesn't use the verbs properly.

Would you care to point out where in the HTTP RFCs it requires the use of certain methods for certain operations? The reality is, you can do whatever you like as far as HTTP is concerned. In fact, only GET and HEAD are required to be implemented, all the other methods are optional. HTTP does not have "verbs". That is REST. Just because they aren't using a REST API, doesn't mean they are not HTTP compliant.

I'm not sure that it actually violates the letter of the law of the spec, but I think it definitely violates the spirit, based on this section: http://tools.ietf.org/html/rfc2616#page-51.

I thought that GET (along with a few other methods) were supposed to be "safe" and not result in any action on the server except possibly logging and stuff like that? Is this required to be HTTP compliant or is this more of a recommendation?

Re: How Not to write a "REST" API

#99

Post by maratd »

bsenftner wrote: post #35

I don't hear people mention Drupal much here at HN. I assumed it was the learning curve; but anyway.. I point your interest over at https://drupal.org/node/783460 where the Services 3.0 module's REST API development framework is demonstrated with an example of creating a simple RESTful CRUD service. For ambitious WebApps & WebAPIs, Drupal provides great scaffolding for development. And it looks like the Drupal8 branc…

Using Drupal to create a RESTful API is like using a tank to hammer in a nail. It takes about 50 lines of code to write a simple RESTful API in pure PHP.

Take a look at http://www.recessframework.org/page/towards-restful-php-5-ba... to learn how to get started. Also, the dude who wrote that has a framework that is built around REST. You don't really need it though.

Re: How Not to write a "REST" API

#100

Post by SomeOtherGuy2 »

alexchamberlain wrote: post #97
SomeOtherGuy2 wrote: post #88

Earlier quoted context omitted.

Would you care to point out where in the HTTP RFCs it requires the use of certain methods for certain operations? The reality is, you can do whatever you like as far as HTTP is concerned. In fact, only GET and HEAD are required to be implemented, all the other methods are optional. HTTP does not have "verbs". That is REST. Just because they aren't using a REST API, doesn't mean they are not HTTP compliant.

RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Now read it. Notice how it is all "SHOULD" and "SHOULD NOT". You can do whatever you want and still be HTTP compliant. Using practices that are not recommended is not the same as being non-compliant.
Post reply on HN