Contributions > Service Genres > Add 1.1 Login
  Minimize

 
      Minimize
Name
 
  • Name: Add
  • Alternate Name: CRUD
Rationale
 

This Service Genre has been prepared from a number of dispararte projects and work. This Service Genre has been developed to provide a description of the behaviours required when a service wishes to offer functionality allowing for the creation, update and deletion of data items within collections of like data.

Classification
 
Domain(s) [ ] Learning & Teaching [ ] Research
[ ] Libraries
[ ] Administration
[ ] IT Services
[X] Common
Maturity [ ] Immature [X] Mature
Development Scale [ ] Isolated [X] Ubiquitous
Status [X] Approved [ ] Placeholder
[ ] Unapproved
[ ] Superseded
[ ] Withdrawn
Confidence Level [ ] High [ ] Medium [ ] Low
Version
 
  • v1.1
Version History
 
Version Date Author Description Organisation / Project
v1.1
2007-03-06 Phil Nicholls
reviewed by eFIG
JISC
Description
 

This Service Genre describes the insertions of objects into collections of like objects. This MAY also include the metadata associated with an object. An ICT architecture that offers a service of the Add genre will be able to support remote updates of items within their collections.

Add implementations will typically also offer the users the functionality to update and delete existing objects within collections.

Typical implementations assign a unique identifier to objects within their collections, and also persist data in some form until it is explicitly removed. However, it is not inconceivable that other processes could consume added data very rapidly; or that a collection would be deleted at the end of a session.

As defined the Add Service Genre is not access controlled. Any client may attempt to contact an Add service end point. There are no authentication controls. The service end point is responsible for determining which clients can Add content.

Functionality
 

The Add Service Genre supports three functions:

  1. Create – The creation of a new object within the collection. (Includes collections of size zero – e.g. the first entry in a blog, or the first record within a table in a database).
  2. Update – The update of an existing object within the collection. This is an atomic operation, updating the entire object, rather than altering one or more individual data fields within the object.
  3. Delete – The removal of an existing object from a collection. This is an atomic operation, and the object being removed must exist within the collection.

No other functionality is defined. The functionality that is defined MAY be extended.

Usage Scenarios
 

Some examples of where Add services might be employed are Blogs – where users can add new postings (and comments), Digital Libraries, where new digital objects can be added to existing collections, and e-Archives, where digital copies of artefacts can be added to the online database.

Applicability
 

Add Services SHOULD be strict as regards the types of data that they accept. Add Services SHOULD NOT be used to process any generic data.

Requests & Behaviours
 

In all cases, implementing services SHOULD be strict on the type of data being accepted.

Create SHALL meet the following conditions:

  • The Request SHOULD specify:
    • The content data.
  • The Request MAY specify:
    • Metadata regarding the content data.

Update SHALL meet the following conditions:

  • The Request SHOULD specify:
    • The target content data to update.
    • The content data
  • The Request MAY specify:
    • Metadata regarding the content data

Delete SHALL meet the following conditions:

  • The Request SHOULD specify:
    • The target content data to be deleted

Responses SHOULD indicate error conditions.

NB: Service Expressions MAY specify identifiers instead of content data for targets in the Update and Delete requests.

Use & Interactions
 

Individual Service Expressions SHOULD provide models showing how clients interact with service interfaces.

Structure
 

 

Applicable Standards
 

None

Design Decisions and Tradeoffs
 

Applications making use of Add style services should pay particular attention to issues around Authentication and Authorisation – to ensure the integrity of the collections being manipulated.

Implementation Guidance and Dependencies
 

 

Known Uses
 

 

Related Service Usage Models (SUMs)
 
Related CORE SUMs
 

 


Intellectual Property Rights: This document is governed by the e-Framework Intellectual Property Rights Statement [http://www.e-framework.org/Default.aspx?tabid=738]. © Copyright, JISC, DEST & e-Framework Partners 2007. This document may be used under the Creative Commons Attribution-ShareAlike 2.5 Australia License [http://creativecommons.org/licenses/by-sa/2.5/au/].


The words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC 2119].

The Service Genre description uses e-Framework Service Genre description elements as of 2006-12-09, updated to include draft e-Framework service classifications. Other terms, e.g., client, provider, and resource, are used as defined in the e-Framework.

 
Related SUMs   Minimize
 
    Minimize
Unless otherwise noted material from the e-Framework website can be downloaded for your own use under a Creative Commons Attribution-ShareAlike 2.5 Australia License
CreativeCommons-by-sa.png
 
Thursday, August 28, 2008
Copyright e-Framework Partners 2006 - 2008

Terms and Conditions

Privacy Statement