This is a continuation of a series of articles on crowdsourcing application and including the most recent article. The original problem statement is included again for context.  

Social engineering applications provide a wealth of information to the end-user, but the questions and answers received on it are always limited to just that – social circle. Advice solicited for personal circumstances is never appropriate for forums which can remain in public view. It is also difficult to find the right forums or audience where the responses can be obtained in a short time. When we want more opinions in a discrete manner without the knowledge of those who surround us, the options become fewer and fewer. In addition, crowd-sourcing the opinions for a personal topic is not easily available via applications. This document tries to envision an application to meet this requirement.  

The previous article continued the elaboration on the usage of the public cloud services for provisioning queue, document store and compute. It talked a bit about the messaging platform required to support this social-engineering application. The problems encountered with social engineering are well-defined and have precedence in various commercial applications. They are primarily about the feed for each user and the propagation of solicitations to the crowd. The previous article described selective fan out. When the clients wake up, they can request their state to be refreshed. This perfects the write update because the data does not need to be sent out. If the queue sends messages back to the clients, it is a fan-out process. The devices can choose to check-in at selective times and the server can be selective about which clients to update. Both methods work well in certain situations. The fan-out happens in both writing as well as loading. It can be made selective as well. The fan-out can be limited during both pull and push. Disabling the writes to all devices can significantly reduce the cost. Other devices can load these updates only when reading. It is also helpful to keep track of which clients are active over a period so that only those devices get preference.    

With these the Campaigns program service provides a consistent and uniform responses program that enables individuals to crowdsource advice regardless of the user interface or advice they use. The setup of the campaigns responses as correlated data in the store enables faster and easier access to the data for rendering purposes. 

The APIs for Campaigns that performs the create-update-delete as well as querying are REST APIs for a resource named Campaigns, which looks like the following:

• Storing campaigns in a database with user details such as 

o Campaign-form, 

o user relationship, 

o target URL to fulfil the campaign from backend store, and 

o active versus inactive state for the campaign processing

• API to create/update/delete campaigns that includes:

o GET /api/v1/campaign/ to list

o POST /api/v1/campaign/ to create

o GET /api/v1/campaign/:id/ to lookup 

o PUT /api/v1/campaign/:id/ to edit

o DELETE /api/v1/campaign/:id to delete a subscription

• List and implement campaign types

o a name in the name.verb syntax.

o a payload to simply mirror the representation from the standard API.

• send hooks with POST to each of the target URLs for each matching campaign

o compiling and POSTing the combined payload for the triggering resource and hook resource

o sending to known online retail stores with the Campaign where X-Hook-Secret header has a unique string and one that matches what was issued by the backend retail store.

o confirming the hook legitimacy with a X-Hook-Signature header

o Handling responses like the 410 Gone and optionally retrying connection or other 4xx/5xx errors.