wiki:WP4/Agile/Sprints/03/url-design

Initial Thoughts on Metafor URL design to supplement attached note

  1. The metafor domain will not live for long ...

The key decision is to choose a base URL for the "Metafor" portal and ensure that DNS resolution will resolve this to the appropriate ip address. The domain name will last as long as the DNS registration is kept upto date.

  1. restful resources don't necessarily know what type they are ... but ... it's easier to build services that know what they are doing if they know what they are doing it with ... (my problem with rest is that's all about verbs, and not about nouns, rest uses media type for the latter, which can be dangerous).

* REST is all about resources, i.e. nouns. A REST service endpoint manages resource state via a standardised set of HTTP operations; i.e. verbs. The degree of intelligence that a REST service implementation has of the resource that it is managing is all down to the controller code.

  • When a consumer dispatches an HTTP request to a REST service endpoint then the resource representation (e.g. xml, json, yaml ...etc) & version is embedded within the HTTP request Accept header - how is this at all dangerous? The only danger is that the consumer may not know how to construct a REST HTTP request correctly, this is an issue of training & documentation.

  1. The UID will be unique, but the same document may exist in more than one place ...
  2. But encapsulation will add interesting problems. For example, the questionnaire will output simulation documents which encapsulate instances of models and platforms. The UID of the simulation will be the same whether or not the document includes those encapsualted instances or links to them.
  3. It looks to me like we'll need a resolution service. Give it a uid, find all instances where-ever they live (in replication land).

So this means that an instance management service, i.e. that which manages CIM instance persistence within the portal, will need to liase with a "resolution service", i.e. that which keeps track of the CIM instance publishing. One aspect of this intra-service interaction is to take into account the collection of all nodes within a CIM instance that ultimately derive from the CIM Document UML stereotype. The array of potential CIM workflow scenarios need thorough documenting.

See attached technical note.

Attachments