Web application with web service (REST) design considerations

User Interfaces

Usually there are at least 2 interfaces involved in designing a web application (SaaS) or internal/intranet application

  • Public facing – Product information and signup/registration process
  • Application – The application/service being used, usually protected by a logging-in process
  • Administrative application – An internal-facing application that is used for administering the application.There are 2 approached in this regard – combined functionality or separate.Reusing the existing application and including administrative features into it cuts down on development effort but increases risk for vulnerabilities and exploitation.Creating a separate application might require additional efforts, but this can be secured by using various security features and mechanisms (IP whitelisting, trusts hosts, firewalled appliances etc)

For each of the interfaces that are required, the following should be considered:


  • Hard validations
    • Generally, model data validations should happen on the server. This is to ensure that all data is valid before proceeding with CRUD operations, especially when passing data through a HTTP POST body (typically in JSON format) as this is text based. Another reason why hard validations are should occur on the server (or end-point) is because you might decide to expose the endpoints to other 3rd party implementations. This will ensure data consistency, no matter what the implementation is.Validations could include one or more of the following:
      • Mandatory fields
      • String lengths (max lengths)
      • Range validations
      • Number validations
      • Date validations
  • Hard versus soft delete (development)
    • Some designs favour soft deletes of data to facilitate easy data recovery (and possibly for audit purposes). Soft delete involves flagging data as deleted as opposed to physically removing it through a “hard” delete. Naturally soft deletes adds additional administrative overheads as this data would need to be removed or archived through some sort of regular house-keeping process.
  • Data-domain validation
    • Ensure that data (such as customer information) that is send back is updated in the correct context – in other words – the customer might be related to a parent entity, but the parent entity reference was altered to insert the user into a different parent in order for someone to gain access to other data to which he normally wouldn’t have access to.
  • Compression (infrastructure)
  • Project structure (Server-side)
    • Controllers
    • Factories
    • Business logic
  • Security
  • Exception Handling
    • Useful logging
  • Configuration settings (configuration file vs database settings)
  • Permanent vs recoverable errors
    • There is nothing more frustrating than using an application that at some point shows an unrecoverable stop-error with information that makes no sense. If the error is permanent (internal failure that prevents application from continuing – which is hopefully a point one never reaches this point. Rather present a general error message and alert the developers using some form of transparent mechanism. Recoverable errors mostly boils down to some form validation error that can be corrected on the spot.
  • Data transfer object models – Especially web facing applications – obscure critical information that can identify data and allow data to be altered or traced back to a specific point of origin. Unnecessary data is striped away and transformed in useful ways to be used by the client. So returning the data model verbatim is not recommended. Practical example is to substitute primary keys (integers) for GUID’s.
  • Boilerplating
  • Template vs models – Generating an entire template (translations) or only providing models to the client-side
  • Localisation
  • Translations
  • Logging
  • Auditing
    • Internal – User activity
    • External – Security measure notifying user of critical data changes


  • Soft validation
  • Project structure
  • HTML/views
  • Security – The client side should never be involved in manipulation of security credentials. Security information should always originate at the server, and passed back by the client accompanying client requests unaltered.
  • Controllers (AngularJs)
  • Factories (AngularJs)
  • Boilerplating – Bootstrap
  • Scaffold generators vs manual scaffold
  • Package managers (Bower)
  • Locality
  • Translations
  • Lazyloading
  • Compiled stand-alone dependency library
  • Third-party frameworks – ReactJs/NodeJs/jQuery
  • Third-party plugins (Preferably managed through a package manager to maintain versioning)
  • Views
    • Dynamic (provided by the server)
    • Static (front-end HTML)

Build/deploy process

  • Minification – compressing static content – similar to Cloudflare or dynamic compression as supported by various web servers. Should be combined with obfuscating and implemented during the development process so it can be tested. (less webserver overheads)
  • Obfuscating – complicating the ease of which client-side code (such as Javascript) can be understood by humans. Should be combined with minfication  and implemented during the development process. (additional security overhead)


  • Scaffold generators vs manual scaffold
  • Data objects vs Data transfer objects
    • GUID (indexable) vs ID
  • Project release documentation
  • SSL
  • Content-caching
  • Source control
  • Nightly builds
  • Deployment environments (STAGE/TEST/PROD)
  • Peer reviews
  • Merging strategies
  • Continuous integration
  • Testing
  • Package managers (Nuget/Composer/NPM)
  • Agile/LEAN methodologies
  • Frameworks
    • REST
    • ORM
      • Migrations


  • Content-delivery networks (CDN) vs local (Cloudflare vs self-managed) – Advantage of using CDN’s is that static content is cached and served faster to the client
  • Security
    • Mitigate Denial-of-Service (DoS) and
    • Brute-force attacks

Leave a Reply

Your email address will not be published. Required fields are marked *