So fundamentally the approach we have taken is to build a registry/repository based on REST concepts. And as we looked at the REST space, we kept noticing how close the Atom Publishing Protocol (APP) is to our needs, so we’ve made that the public remote API to access the repository. Of course, if you are just browsing the registry, you only need a browser - APP is mainly there to support updating resources.
The Systinet registry heavily relies on RESTful HTTP, too, but it’s still great to see this. If the road to acceptance of REST, Atom and AtomPub in hardcore SOA camps leads through the metadata use case first, that’s perfectly fine by me.
Funny thing .. I just did something quite similar .. I converted all the calls present in the UDDI Subscription API to use ATOM. Creating subscriptions, viewing , deleting etc. the whole thing.
Ofcourse me being a lowly student ,I couldn’t get the resources to test it all out/publish.
Other than that , has anyone actually seen a major advantage to this sort of work? Other than the simplicity that a new registry will bring (i.e it won’t inherit any of the UDDI cruft), what other advantage would this bring ? The question of network load is not that important over intranets imho, whereas over the internet every service will use HTTPS so no caching would exist.
So other than simplicity in design , exactly what advantage does this give ?
I know all the REST advantages and I am an advocate of REST , so don’t run me down with a list of the advantages REST provides in general. I am looking for a list of advantages specific to this use case (intranet registry for services). Using simple XML instead of SOAP falls in simplicity too.