# Structured Data REST Protocol for End to End Data Mashup
## Structured Data Rest Protocol
### The Model of Proposed SDRest Protocol  
The model of the proposed protocol called Structured Data REST Protocol (SDRest) has been shown in Figure 2 which is the extension of existing REpresentational State Transfer [5] (REST) protocol for end to end data mashup. Here, the term \"end to end data mashup\" implies performing the data mashup directly between any two stakeholders (EU, MSP and DSP).  
The SDRest protocol has two entities called Data Service Producer/Provider (DSP) and Data Service Consumer (DSC). DSP will produce structured data which would be consumed by DSC using the proposed SDRest protocol. In our proposed work, the entity which takes services of MSP or DSP would be called DSC and entity which provides data services to DSC would be called DSP. Thus, end user or MSP may play the role of DSC and MSP/DSP may play the role of DSP. In Figure 1, EU#01 is DSC for MSP#01 and DSP#03 both and MSP#01 is further DSC for DSP#01 and DSP#02. The DSP is required to publish the data services through Mashup Data Service Identifier (MDSI) so that DSC can access the data in the structured format using standard REST protocol. Mashup Data Service Identifier (MDSI) is the unique REST URI used by DSC to fetch the required data from DSP. The major contribution in this model is introducing the concept of one or more Structured Data Mashup Box (SDMB) which would be used by Data Service Consumer (DSC) to view, store or forward required mashed up data.  
The data service consumer as end user will use Structured Data Mashup Box (SDMB) to store and view the required mashed up data whereas data service consumer as MSP will perform mashup on the data received from various DSPs/MSPs and forward it to respective data service consumer. Further, the group of SDMBs called End User Data Mashup (EUDM) would be explored by end user to see the integrated UI view of mashed up data (fetched from multiple MSPs/DSPs) in a single screen which is the main objective of the proposed work. According to our proposed model, DSC (the REST  
Figure 2: Model of Structured Data REpresentational State Transfer (REST) (SDRest) Protocol.  
client) will read all the Structured Data Records (SDRs) made available by DSP through Mashup Data Service Identifier (MDSI) and filter component will parse each SDR to check whether it is a valid SDR or not. Transformation component will transform each valid SDR into proper format so that it can be populated into Structured Data Mashup Box. The structured data records, which are successfully populated into SDMB would be called Mashed up Data Records (MDRs).  
Valid SDR would be transformed and populated into appropriate SDMB at DSC's end using proposed algorithm (See Section 5.15) whereas invalid SDRs would be ignored. Cloud computing paradigm called Structured Data as Service (SDaaS) or Mashup Data Service (MDS) at MSP's/DSP's end will generate (compose) one or more structured data records and publish them so that they can be accessed by DSCs for data mashup. Each publication of MSP/DSP would be identified by mashup data service identifier. It can be seen from Figure 2 that there are p SDMBs at DSC's end and q SDMBs at DSP's end. Here, p and q may or may not be equal to each other and SDMB at DSP's end is optional but SDMB at DSC's end is compulsory to implement this protocol. Following section describes the system architecture and the working of this model in detail.