Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [emf-dev] exposing Ecore models via web services

Jake,

Let's have these discussions on the newsgroup.  That way more people are likely to find it in the future when they do a search...

More comments below.


Jacob Beard wrote:
Hi Ed,

I have reviewed the resources you linked to. I believe I have a good understanding of what would be required to expose EMF models using the RESTful interfaces already available and HTTP. I'd appreciate it if you (or Kenn), could please let me know if you feel like this sounds like a reasonable solution.

Basically, you set up a Servlet inside of Eclipse that leverages the Resource class that was mentioned in Kenn's presentation:

http://www.eclipsecon.org/2009/sessions?id=272

I'm not too sure where this class comes from. A quick search inside of Eclipse showed a couple of Resource classes available in my workspace. But, basically, you would use the one referenced by Kenn in his presentation.
The EMF one of course: org.eclipse.emf.ecore.resource.Resource.

In each of the HTTP method handlers (GET, POST, PUT, DELETE), upon a user request, you perform the following action: depending on what the Resource class is able to accept, you may need to transform the http: request URI to some other URI such as file: or platform: which the Resource class can accept. You then send that URI into the Resource.
Yes, EMF provides a URIHandler that fully supports HTTP so a server need only implement the full HTTP protocol.  Most servers support only read-only access...

If it's a PUT, you would instantiate a new resource at that URI. If it's an HTTP GET, you would return that current resource, encoded in XML or JSON.
Yes, it's just bytes as far as the transfer protocol is concerned.  The resource implementation itself determines the meaning of those bytes.  There is, for example, BinaryResourceImpl which supports a much smaller and more efficiently processable representation.
If it's a POST, then you would assume that you're trying to update an existing resource, and so would use a standard Remote Procedure Calls pattern; you would retrieve the resource based on the URL, then look at the post data for the method name and arguments to invoke on the retrieved resource, then return the result as XML or JSON.
We don't make use of POST.  GET gets the bytes and PUT saves the bytes, either overwriting an existing resource or creating a new resource.
Finally, a DELETE would retrieve the resource based on the URI and then do whatever is needed to delete it.
I'm not sure it needs to retrieve anything.  Just deleting it is good enough.

I believe that the Servelet code that maps the HTTP methods onto the restful interfaces can be generated automatically using the standard genmodel.
I imagine such a mapping can be generic, just like the whole XML serialization framework is completely generic.  I.e., what will be model-specific about this mapping?

Please let me know if this sounds reasonable. Thanks,
It sounds close.  Let's use the newsgroup for follow ups.  Maybe I'll get a chance to visit Montreal one of these days.  I haven't been there for a great many years...

Jake

On Wed, Mar 25, 2009 at 3:20 PM, Jacob Beard <jbeard4@xxxxxxxxxxxx> wrote:
Hi Ed,

Thanks again for the quick response. I'm currently reviewing the slides from Kenn's presentation:

http://www.eclipsecon.org/2009/sessions?id=272

You're right, it probably would have been very helpful to have attended. Maybe next year :)

I'll let you know if I still have questions on this. Thanks,

Jake


On Wed, Mar 25, 2009 at 2:01 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:
On the other hand, you said that EMF's resource design is fully RESTful. Could you please explain this a bit more, or point me to a resource that does?
Kenn's EclipseCon tutorial was about this topic.  Why weren't you there? :-P 

In https://bugs.eclipse.org/bugs/show_bug.cgi?id=191077 there is a little servlet that I used to test that save and delete work properly via HTTP.

In general REST is just a set of principles around the idea of  how the resources are uniformly addressed and the small number of operations that can be applied to those resources.  An EMF resource set effectively works like a browser where pages are like resources, addressed by a URI, and follow links opens new tabs.  How more RESTful can you be? :-P





Back to the top