Versions Compared

Old Version 19

changes.mady.by.user Jiri Kremser

Saved on

compared with

New Version 20

changes.mady.by.user Jiri Kremser

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

In other words, only new xml attribute expectedContentTypes from namespace with URI http://www.w3.org/2005/05/xmlmime is set to the value application/octet-stream.

Affected API-M Methods

  • ingest
  • getObjectXML
  • export (response)
  • modifyDatastreamByValue

Wiki MarkupThere is little discrepancy&nbsp;between _little discrepancy between API-M_ WSDL definition of method&nbsp;_modifyDatastreamByValue_ and of method modifyDatastreamByValue and it's web definition on ([https://wiki.duraspace.org/display/FCR30/API-M#API-M-modifyDatastreamByValue|https://wiki.duraspace.org/display/FCR30/API-M#API-M-modifyDatastreamByValue]). WSDL says attribute&nbsp;_dsContent_ is of type *byte\[\]*, but web says String. I suppose, the *byte\[\]* as the correct type.&nbsp; <span style="color: #808080"><em>(You're correct, Jiri. I've fixed the documentation. - Chris)</em></span>says attribute dsContent is of type byte[], but web says String. I suppose, the byte[] as the correct type.  (You're correct, Jiri. I've fixed the documentation. - Chris)

Affected API-A Methods

  • getDatastreamDissemination

...

Methods marked as <span style="color: #ff0000">red</span> has an input parameter of type *byte\[\]* and <span style="color: #0000ff">blue</span> methods has output value of type *byte\[\]*as red has an input parameter of type byte[] and blue methods has output value of type byte[].

Changes to WSDL

Since API-A and API-M wsdl files both use the include directive inside their <types> element, the changes will be made only to fedora-types.xsd.

...

  • 1.a
    •  The easiest solution
    •  The smallest set of operations in the API.
    •  No need for new endpoints/wsdls
  • 1.b
    • Consistent (all MTOM operation has "MTOM" in name)
    • Still easy
    • No need for new endpoints/wsdls
  • 2.
    • 100% guarantee of backward compatibility
    • This method is the best practise, when doing backward compatible changes to WS API 
  • 3.
    • The WS endpoints remain the same and can handle all versions of API based on the particular namespace (now the namespace inside the SOAP messages is http://www.fedora.info/definitions/1/0/types/. I suggest something like http://www.fedora.info/2011/7/[definitions/types/|http://www.fedora.info/definitions/2011/7/29/types/]  (W3C convetion)).
    • will not break "low lvl clients" i.e. clients that are not generated from wsdl like curl, because the endpoint is still the same and if such "low lvl client" wants to start use new version of WS the only change for him is to change the structure of SOAP by changing the namespace. In the Java/.NET world this is a minor advantage, but if the client is written in, say, bash, it may help.
    • probably most robust solution with keeping in mind the possible future changes to API (once the infrastructure around is implemented, the addition of new version of API is easier)

...

suggestion:

prefix

old

new

fedora-types

http://www.fedora.info/definitions/1/0/types/Image Removedhttp://fedora-commons.org/2011/07/definitions/types/Image Removed

fedora-api

http://www.fedora.info/definitions/1/0/api/Image Removed http://fedora-commons.org/]2011/07/definitions/api/ Image Removed

References