#http
4 posts

Design principles for your HTTP APIs

Impose consistency so that similar endpoints behave in similar ways, even in edge scenarios, with consistent vocabulary, URL structure, request/response formats and error handling.
Read more

Design principles for your HTTP APIs

  • Impose consistency so that similar endpoints behave in similar ways, even in edge scenarios, with consistent vocabulary, URL structure, request/response formats and error handling. This will help ensure that users don’t need to read extensive documentation and handling updates becomes easier for developers.
  • Achieve performance by avoiding early optimization, waiting until you have the right metric in place to optimize based on hard data - and collect that data from day one, with an APM tool.
  • Use metrics to inform evolution, so that you update and add features based on actual user usage of endpoints to avoid or minimize disruptions to existing implementations.
  • For complex APIs, avoid a 1:1 mapping between database tables and API resources. Build in usability by simplifying business transactions to require a single API call rather than multiple. If it isn’t possible, be as flexible as you can.
  • Adopt simplicity by building on top of universally accepted standards and tools. This will mean less overheads and less room for mistakes.

Full post here, 7 mins read

HTTP headers to secure your app for the busy web developer

Set an X-Frame-Options header to prevent someone from creating an iframe wrapper around your site to clickjack your site. Your safety options are DENY, SAMEORIGIN, and ALLOW-FROM.
Read more

HTTP headers to secure your app for the busy web developer

  • Set an X-Frame-Options header to prevent someone from creating an iframe wrapper around your site to clickjack your site. Your safety options are DENY, SAMEORIGIN, and ALLOW-FROM.
  • You can set X-XSS-Protection to block Reflected XSS (cross-site scripting) attacks.
  • Set the X-Content-Type-Options header to force browsers to respect the server-specified file type, preventing a Javascript injection through an HTML file.
  • Apply Strict Transport Security to refuse to connect as HTTP, enforcing HTTPS instead.
  • Prevent hackers from reading cookies by using HttpOnly to prevent Javascript accessing cookies, blocking an XSS attacker, and by using the Secure attribute to allow cookies to transfer only over HTTPS and not HTTP.

Full post here, 4 mins read

5 ways to make HTTP requests in Node.js

Request is a simplified HTTP client which is more user-friendly that you can install as a dependency from npm. It is easy to use and you can support Promises with the request-promise library.
Read more

5 ways to make HTTP requests in Node.js

  • You can use the default HTTP module in the standard library. It saves you the trouble of installing external dependencies but is not as user-friendly as other solutions.
  • Request is a simplified HTTP client which is more user-friendly that you can install as a dependency from npm. It is easy to use and you can support Promises with the request-promise library.
  • Axios is a Promise-based client for both the browser and Node.js, good for asynchronous code and more complex uses. It parses JSON responses by default and can handle multiple concurrent requests with axios.all.
  • SuperAgent, that is primarily used for Ajax requests in the browser, also works in Node.js. It offers functions like query() that you can chain on to requests to add parameters, and as with Axios, you don’t need to parse JSON responses yourself.
  • Got is a more lightweight library compared to Request, etc. Got work with Promises as well.

Full post here, 4 mins read

The headers we don’t want

Some unnecessary HTTP headers you want to avoid. Vanity headers such as server, x-powered-by and via. Some headers, such as p3p, expires, and x-frame-options represent deprecated standards.
Read more

The headers we don’t want

Some unnecessary HTTP headers you want to avoid:

  • Vanity headers such as server, x-powered-by and via offer little value to end-users or developers but at worst they divulge sensitive information.
  • Some headers, such as p3p, expires, x-frame-options and x-ua-compatible, represent deprecated standards.
  • Headers that are only useful to debug data but are not recognized by any browser, such as x-cache, x-request-id, x-aspnet-version, x-amzn-requestID. As a developer, you may want to keep them on but know that removing them makes no difference to how your pages are rendered.
  • x-robots-tag is a non-browser header only useful when the requesting agent is a crawler.

Full post here, 7 mins read