Ask HN: issues involved with implementing secure RESTful APIs

There is nothing fundamentally different about a RESTful API compared to any other type of HTTP request.

Use SSL to encrypt all sensitive data during transit, and think carefully about the best authentication method for your circumstances: you could consider the use of OAuth2 so that developers can authenticate your users, without requiring the users to expose their credentials.

There are a few ideas here: http://stackoverflow.com/questions/7551/best-practices-for-s...

RE: designing a set of reusable APIs, or APIs built in reusable components A lot of what results in a successful, security-conscious API stems from adherence and discipline to good development practices and thinking through your API. A few that have really helped me:

- leverage the power of a suite of SCM/dev tools that match your work flow - realign your work flow to include good development practices: scm such as hg/git, rst documentation with sphinx/etc, build and testing suites - use a simple svg editor for diagraming (anyone can use inkscap) - learn how to think of these abstract model-relationships spatially and relationally - build new functionality out of tests that define your goals/intentions and the limitations imposed - use automated tests at various levels, to ensure the above fits your design - write code with the intention that it be reused, decouple sensibly - understand that there is 'the right way' and 'just-another-hack', try to go 'the right way' as often as you can, you'd be surprised how much it saves you in the long run

Most web APIs could be broken up into a standard set of steps: - initial authentication & authorization, note the difference between these steps, of request source - validation & verification of request data - processing & preparation of request/response data - formatting of response - response & backchannel communication

consider how your APIs can share common code, use APIs internally where it appropriate. decouple components. for example, your data processing components could function independently of the formatting of the input data, and which could be different from the response formatting itself. offer flexibility to your clients and support good development practices everywhere.

use white lists instead of black lists. "what is allowed" over "what is not allowed" as it easier to extend than patch. hack your system, bend it and break it, consider a vulnerability assessment application. consider your audiences and who would want to break your app, intentionally or not.