On 12/21/2014 3:54 AM, Markus KARG wrote:
> Bill,
>
> thank your for that link. It is good to see that actually there is a third
> solution in-field besides mine and Casey's. But browsing your docs, some
> drawbacks are also apparent:
> * Whether structural links shall be working so to be decided at resource
> method level. IMHO this is the wrong place. An improved separation of
> concerns could be reached in my proposal, as the resource method stays clean
> but the decision is made at the model level. Hence, it would work with any
> methods of any applications when working against the same model.
> * The resource classes have to be modified using proprietary
> RESTServiceDiscovery fields. My proposal is vendor-neutral and does not
> impose any changes to the resource class.
What are you talking about? If RESTServiceDiscovery as added to JAX-RS
2.1 spec it would become vendor neutral.
> * Your solutio just works with Atom links, XML and JSON. Mine is a
> transparent API suitable for ANY kind of in-document links, and ANY
> link-enabled MIME type.
>
It only works with our XML and JSON providers because that's the way it
was implemented.
But, I never said I was pushing our implementation. As I said before,
it is not very popular and personally I'd never use it. I linked to our
implementation to generate ideas. Right now, I'm against any new
Hypermedia API. I just haven't seen one I really like yet.
> To sum up, I appreciate your existing technology by my proposal is about a
> vendor-neutral API instead. :-)
>
By "vendor-neutral" do you mean that MBW/R can be generic and reusable?
I don't agree that your proposal does this :) See my other email.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com