Home » Modeling » EMF » Re: [emf-dev] exposing Ecore models via web services
| Re: [emf-dev] exposing Ecore models via web services [message #428764] |
Mon, 30 March 2009 04:29  |
 Jake 
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
[Note to anyone just visiting this thread: it started on emf-dev and I just
now moved it here.]
Hi Ed,
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.
Excellent, I've been looking over the JavaDocs.
>>
>> 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...
OK, I think I understand. You would still need to create custom HTTP method
handlers, but their tasks would be fairly lightweight (at least for GET,
PUT, and DELETE; see more for POST below), which would basically be to feed
the unaltered http:// URI from the HTTP request into a new Resource. If
it's GET, return the resource, if it's PUT, instantiate a new instance of
that particular resource and return it, and if it's DELETE, delete the
resource. Is this correct?
So far, this sounds like a fairly lightweight task (because, so far,
Resource is doing all the heavy lifting :P). Are you aware of whether
anyone has implemented this before? I looked at the code that you linked to
on that bug report, and it was doing something similar, but was
instantiating Files from file paths, and not using Resources.
>>
>> 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.
OK, I believe I understand this now. You have subclasses of ResourceImpl
which determines how the resource will be serialized. You could, for
example, implement a JSONResourceImpl, which returns a lightweight
representation of the resource formatted in JSON as opposed to EMOF XMI,
correct? Come to think of it, this might actually be useful, for
compatibility and performance purposes on the browser client, but wouldn't
be a high priority... XMI would be fine to start.
>> 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.
OK, I think I understand. But, I was thinking of POST as the U in CRUD. What
if you want to update an attribute of an EObject instance that has been
retrieved via a Resource? Or what if you wanted to invoke a method on it? I
think in Kenn's presentation, after a new Resource is instantiated, you are
just able to use normal Java method calls on the retrieved object, because
you are working in Java. But of course, you can't do that if you have a
remote client and alien environment.
I believe the question then, is is there a way to do this RESTfully via
HTTP? Is this already handled by Resource? If so, I'd appreciate it if you
could please explain which HTTP method it uses (probably PUT), and what the
URI looks like (I don't remember seeing this in Kenn's slides). Maybe this
ends up looking like a DELETE and a CREATE of a particular EAttribute and a
DELETE and CREATE on its link to a corresponding EObject, although this
seems inefficinet... On the other hand, if there's not currently a way to
do this, perhaps it would be best to map it to POST. I'm not sure whether
this logic would be better off going into a subclass of Resource, or in the
HTTP server POST handler. Probably the 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.
Yes.
>>
>> 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?
I was imagining you would need to generate some scaffolding to handle Update
operations. I'm still not clear on how update will work given the current
infrastructure, but I think you're right, it should be possible to add
generic logic to either the servlet or the Resource subclass in order to
handle all CRUD operations, and not need to rely on anything specific to
the generator model.
>>
>> 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...
It's certainly beautiful here in the spring.
Thanks again for your help and feedback on this. I feel like I'm getting
close to being able to put a solid proposal together.
Jake
|
|
|
| Re: [emf-dev] exposing Ecore models via web services [message #428777 is a reply to message #428764] |
Mon, 30 March 2009 10:31  |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040509020206020109000005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Jacob,
Comments below.
Jacob Beard wrote:
> [Note to anyone just visiting this thread: it started on emf-dev and I just
> now moved it here.]
>
> Hi Ed,
>
> 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.
>>
>
> Excellent, I've been looking over the JavaDocs.
>
>
>>> 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...
>>
>
> OK, I think I understand. You would still need to create custom HTTP method
> handlers, but their tasks would be fairly lightweight (at least for GET,
> PUT, and DELETE; see more for POST below), which would basically be to feed
> the unaltered http:// URI from the HTTP request into a new Resource. If
> it's GET, return the resource, if it's PUT, instantiate a new instance of
> that particular resource and return it, and if it's DELETE, delete the
> resource. Is this correct?
>
Yes, though put can overwrite.
> So far, this sounds like a fairly lightweight task (because, so far,
> Resource is doing all the heavy lifting :P). Are you aware of whether
> anyone has implemented this before? I looked at the code that you linked to
> on that bug report, and it was doing something similar, but was
> instantiating Files from file paths, and not using Resources.
>
As far the the URIConverter is concerned, it just needs to deal with
bytes. So the simple servlet was just storing/fetching those bytes
to/from the file system. Any type of backing store is possible and you
might even parse the bytes again using EMF to create a model instance,
and then store the instance in some structured form perhaps in an object
repository.
>
>
>>> 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.
>>
>
> OK, I believe I understand this now. You have subclasses of ResourceImpl
> which determines how the resource will be serialized. You could, for
> example, implement a JSONResourceImpl, which returns a lightweight
> representation of the resource formatted in JSON as opposed to EMOF XMI,
> correct?
Indeed. The Xtext folks would store it in some truly human readable form...
> Come to think of it, this might actually be useful, for
> compatibility and performance purposes on the browser client, but wouldn't
> be a high priority... XMI would be fine to start.
>
>
>>> 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.
>>
>
> OK, I think I understand. But, I was thinking of POST as the U in CRUD.
No, I think posting (from what I recall without double checking) is more
like appending to a list and even involves allocating a new URI at which
the POSTed contents will appear....
> What
> if you want to update an attribute of an EObject instance that has been
> retrieved via a Resource?
You update it and save the resource. EMF also supports a change
recorder which can keep track of all your changes to build a change
description, so it's also possible to send deltas...
> Or what if you wanted to invoke a method on it?
RPC. I'm not sure RPC is RESTful...
> I
> think in Kenn's presentation, after a new Resource is instantiated, you are
> just able to use normal Java method calls on the retrieved object, because
> you are working in Java.
Yes. You have a local copy of the object in your JVM to work with.
> But of course, you can't do that if you have a
> remote client and alien environment.
>
Not if you expect operations to affect more than just the local copy but
rather have some effect on the server.
> I believe the question then, is is there a way to do this RESTfully via
> HTTP?
I don't know much about RCP. I know it typically relies on
java.io.Serializeable support...
> Is this already handled by Resource?
Definitely not.
> If so, I'd appreciate it if you
> could please explain which HTTP method it uses (probably PUT), and what the
> URI looks like (I don't remember seeing this in Kenn's slides). Maybe this
> ends up looking like a DELETE and a CREATE of a particular EAttribute and a
> DELETE and CREATE on its link to a corresponding EObject, although this
> seems inefficinet... On the other hand, if there's not currently a way to
> do this, perhaps it would be best to map it to POST. I'm not sure whether
> this logic would be better off going into a subclass of Resource, or in the
> HTTP server POST handler. Probably the Resource.
>
As I said, I'm not sure RCP is really a RESTful thing. ...
>
>
>>> 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.
>>
>
> Yes.
>
>
>>> 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?
>>
>
> I was imagining you would need to generate some scaffolding to handle Update
> operations. I'm still not clear on how update will work given the current
> infrastructure, but I think you're right, it should be possible to add
> generic logic to either the servlet or the Resource subclass in order to
> handle all CRUD operations, and not need to rely on anything specific to
> the generator model.
>
>
>>> 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...
>>
>
> It's certainly beautiful here in the spring.
>
> Thanks again for your help and feedback on this. I feel like I'm getting
> close to being able to put a solid proposal together.
>
> Jake
>
>
--------------040509020206020109000005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jacob,<br>
<br>
Comments below.<br>
<br>
Jacob Beard wrote:
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">[Note to anyone just visiting this thread: it started on emf-dev and I just
now moved it here.]
Hi Ed,
Comments below:
Jacob Beard wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="http://www.eclipsecon.org/2009/sessions?id=272">http://www.eclipsecon.org/2009/sessions?id=272</a>
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.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">The EMF one of course: org.eclipse.emf.ecore.resource.Resource.
</pre>
</blockquote>
<pre wrap=""><!---->
Excellent, I've been looking over the JavaDocs.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">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...
</pre>
</blockquote>
<pre wrap=""><!---->
OK, I think I understand. You would still need to create custom HTTP method
handlers, but their tasks would be fairly lightweight (at least for GET,
PUT, and DELETE; see more for POST below), which would basically be to feed
the unaltered <a class="moz-txt-link-freetext" href="http://">http://</a> URI from the HTTP request into a new Resource. If
it's GET, return the resource, if it's PUT, instantiate a new instance of
that particular resource and return it, and if it's DELETE, delete the
resource. Is this correct?
</pre>
</blockquote>
Yes, though put can overwrite.<br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">
So far, this sounds like a fairly lightweight task (because, so far,
Resource is doing all the heavy lifting :P). Are you aware of whether
anyone has implemented this before? I looked at the code that you linked to
on that bug report, and it was doing something similar, but was
instantiating Files from file paths, and not using Resources.
</pre>
</blockquote>
As far the the URIConverter is concerned, it just needs to deal with
bytes. So the simple servlet was just storing/fetching those bytes
to/from the file system. Any type of backing store is possible and you
might even parse the bytes again using EMF to create a model instance,
and then store the instance in some structured form perhaps in an
object repository.<br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
OK, I believe I understand this now. You have subclasses of ResourceImpl
which determines how the resource will be serialized. You could, for
example, implement a JSONResourceImpl, which returns a lightweight
representation of the resource formatted in JSON as opposed to EMOF XMI,
correct? </pre>
</blockquote>
Indeed. The Xtext folks would store it in some truly human readable
form...<br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">Come to think of it, this might actually be useful, for
compatibility and performance purposes on the browser client, but wouldn't
be a high priority... XMI would be fine to start.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">post data for the method name and arguments to invoke on the retrieved
resource, then return the result as XML or JSON.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
OK, I think I understand. But, I was thinking of POST as the U in CRUD. </pre>
</blockquote>
No, I think posting (from what I recall without double checking) is
more like appending to a list and even involves allocating a new URI at
which the POSTed contents will appear....<br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">What
if you want to update an attribute of an EObject instance that has been
retrieved via a Resource? </pre>
</blockquote>
You update it and save the resource. EMF also supports a change
recorder which can keep track of all your changes to build a change
description, so it's also possible to send deltas...<br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">Or what if you wanted to invoke a method on it? </pre>
</blockquote>
RPC. I'm not sure RPC is RESTful...<br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">I
think in Kenn's presentation, after a new Resource is instantiated, you are
just able to use normal Java method calls on the retrieved object, because
you are working in Java. </pre>
</blockquote>
Yes. You have a local copy of the object in your JVM to work with.<br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">But of course, you can't do that if you have a
remote client and alien environment.
</pre>
</blockquote>
Not if you expect operations to affect more than just the local copy
but rather have some effect on the server. <br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">
I believe the question then, is is there a way to do this RESTfully via
HTTP? </pre>
</blockquote>
I don't know much about RCP. I know it typically relies on
java.io.Serializeable support...<br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">Is this already handled by Resource?</pre>
</blockquote>
Definitely not.<br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap=""> If so, I'd appreciate it if you
could please explain which HTTP method it uses (probably PUT), and what the
URI looks like (I don't remember seeing this in Kenn's slides). Maybe this
ends up looking like a DELETE and a CREATE of a particular EAttribute and a
DELETE and CREATE on its link to a corresponding EObject, although this
seems inefficinet... On the other hand, if there's not currently a way to
do this, perhaps it would be best to map it to POST. I'm not sure whether
this logic would be better off going into a subclass of Resource, or in the
HTTP server POST handler. Probably the Resource.
</pre>
</blockquote>
As I said, I'm not sure RCP is really a RESTful thing. ...<br>
<blockquote cite="mid:gqphrv$jf5$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Finally, a DELETE would retrieve the resource based on the URI and then
do whatever is needed to delete it.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">I'm not sure it needs to retrieve anything. Just deleting it is good
enough.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I believe that the Servelet code that maps the HTTP methods onto the
restful interfaces can be generated automatically using the standard
genmodel.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
I was imagining you would need to generate some scaffolding to handle Update
operations. I'm still not clear on how update will work given the current
infrastructure, but I think you're right, it should be possible to add
generic logic to either the servlet or the Resource subclass in order to
handle all CRUD operations, and not need to rely on anything specific to
the generator model.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Please let me know if this sounds reasonable. Thanks,
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">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...
</pre>
</blockquote>
<pre wrap=""><!---->
It's certainly beautiful here in the spring.
Thanks again for your help and feedback on this. I feel like I'm getting
close to being able to put a solid proposal together.
Jake
</pre>
</blockquote>
</body>
</html>
--------------040509020206020109000005--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [emf-dev] exposing Ecore models via web services [message #428790 is a reply to message #428777] |
Mon, 30 March 2009 17:26 |
Jake
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
Hi Ed,
Replies below:
>>
>> OK, I think I understand. But, I was thinking of POST as the U in CRUD.
> No, I think posting (from what I recall without double checking) is more
> like appending to a list and even involves allocating a new URI at which
> the POSTed contents will appear....
OK, that sounds reasonable.
>> What
>> if you want to update an attribute of an EObject instance that has been
>> retrieved via a Resource?
> You update it and save the resource. EMF also supports a change
> recorder which can keep track of all your changes to build a change
> description, so it's also possible to send deltas...
>> Or what if you wanted to invoke a method on it?
> RPC. I'm not sure RPC is RESTful...
Yes, you're right about this. I think I may have confused things by talking
about invoking methods. This is not a RESTful pattern, but it was the
easiest thing to think about with respect to the content of Kenn's
presentation, where Java objects were retrieved RESTfully, and then had
operations invoked on them as regular Java objects. But I can't actually
think of a scenario where you would need to do something to an EObject that
could not be expressed with basic CRUD operations, and none of the examples
given in Kenn's presentation would lead me to believe so either.
So, just to be clear, both Create and Update maps to PUT for EMF Resources?
It seems like, because you're overloading the HTTP method, there would then
need to be some canonical way of encoding Create and Update operations in
PUT data, so as to differentiate them. Please let me know about this.
I feel like we're now starting to drill down into implementation details. I
believe I have a good enough understanding now to put together a proposal,
so I'm going to begin working on that, but I'd like to keep this thread
going as well.
Thanks for your help,
Jake
|
|
|
| Re: [emf-dev] exposing Ecore models via web services [message #428792 is a reply to message #428790] |
Mon, 30 March 2009 17:37 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080603020205010404000800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Jake,
Comments below.
Jacob Beard wrote:
> Hi Ed,
>
> Replies below:
>
>
>>> OK, I think I understand. But, I was thinking of POST as the U in CRUD.
>>>
>> No, I think posting (from what I recall without double checking) is more
>> like appending to a list and even involves allocating a new URI at which
>> the POSTed contents will appear....
>>
>
> OK, that sounds reasonable.
>
>
>>> What
>>> if you want to update an attribute of an EObject instance that has been
>>> retrieved via a Resource?
>>>
>> You update it and save the resource. EMF also supports a change
>> recorder which can keep track of all your changes to build a change
>> description, so it's also possible to send deltas...
>>
>>> Or what if you wanted to invoke a method on it?
>>>
>> RPC. I'm not sure RPC is RESTful...
>>
>
> Yes, you're right about this. I think I may have confused things by talking
> about invoking methods. This is not a RESTful pattern, but it was the
> easiest thing to think about with respect to the content of Kenn's
> presentation, where Java objects were retrieved RESTfully, and then had
> operations invoked on them as regular Java objects. But I can't actually
> think of a scenario where you would need to do something to an EObject that
> could not be expressed with basic CRUD operations, and none of the examples
> given in Kenn's presentation would lead me to believe so either.
>
> So, just to be clear, both Create and Update maps to PUT for EMF Resources?
>
Yes.
> It seems like, because you're overloading the HTTP method, there would then
> need to be some canonical way of encoding Create and Update operations in
> PUT data, so as to differentiate them. Please let me know about this.
>
I think of it the same way as if I write to a file. I just write to
it. If the file already existed, then I overwrite it. If not, then
I've created it.
> I feel like we're now starting to drill down into implementation details. I
> believe I have a good enough understanding now to put together a proposal,
> so I'm going to begin working on that, but I'd like to keep this thread
> going as well.
>
Read carefully how POST is different from PUT. I forget the details,
but I'm sure it will become more clear...
> Thanks for your help,
>
> Jake
>
--------------080603020205010404000800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jake,<br>
<br>
Comments below.<br>
<br>
Jacob Beard wrote:
<blockquote cite="mid:gqqvc1$oiu$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
Replies below:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">OK, I think I understand. But, I was thinking of POST as the U in CRUD.
</pre>
</blockquote>
<pre wrap="">No, I think posting (from what I recall without double checking) is more
like appending to a list and even involves allocating a new URI at which
the POSTed contents will appear....
</pre>
</blockquote>
<pre wrap=""><!---->
OK, that sounds reasonable.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">What
if you want to update an attribute of an EObject instance that has been
retrieved via a Resource?
</pre>
</blockquote>
<pre wrap="">You update it and save the resource. EMF also supports a change
recorder which can keep track of all your changes to build a change
description, so it's also possible to send deltas...
</pre>
<blockquote type="cite">
<pre wrap="">Or what if you wanted to invoke a method on it?
</pre>
</blockquote>
<pre wrap="">RPC. I'm not sure RPC is RESTful...
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, you're right about this. I think I may have confused things by talking
about invoking methods. This is not a RESTful pattern, but it was the
easiest thing to think about with respect to the content of Kenn's
presentation, where Java objects were retrieved RESTfully, and then had
operations invoked on them as regular Java objects. But I can't actually
think of a scenario where you would need to do something to an EObject that
could not be expressed with basic CRUD operations, and none of the examples
given in Kenn's presentation would lead me to believe so either.
So, just to be clear, both Create and Update maps to PUT for EMF Resources?
</pre>
</blockquote>
Yes.<br>
<blockquote cite="mid:gqqvc1$oiu$1@build.eclipse.org" type="cite">
<pre wrap="">It seems like, because you're overloading the HTTP method, there would then
need to be some canonical way of encoding Create and Update operations in
PUT data, so as to differentiate them. Please let me know about this.
</pre>
</blockquote>
I think of it the same way as if I write to a file. I just write to
it. If the file already existed, then I overwrite it. If not, then
I've created it. <br>
<blockquote cite="mid:gqqvc1$oiu$1@build.eclipse.org" type="cite">
<pre wrap="">
I feel like we're now starting to drill down into implementation details. I
believe I have a good enough understanding now to put together a proposal,
so I'm going to begin working on that, but I'd like to keep this thread
going as well.
</pre>
</blockquote>
Read carefully how POST is different from PUT. I forget the details,
but I'm sure it will become more clear...<br>
<blockquote cite="mid:gqqvc1$oiu$1@build.eclipse.org" type="cite">
<pre wrap="">
Thanks for your help,
Jake
</pre>
</blockquote>
</body>
</html>
--------------080603020205010404000800--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [emf-dev] exposing Ecore models via web services [message #428793 is a reply to message #428792] |
Mon, 30 March 2009 17:52 |
Jake
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
Hi Ed,
Thanks for the quick response.
>> It seems like, because you're overloading the HTTP method, there would
>> then need to be some canonical way of encoding Create and Update
>> operations in PUT data, so as to differentiate them. Please let me know
>> about this.
>>
> I think of it the same way as if I write to a file. I just write to
> it. If the file already existed, then I overwrite it. If not, then
> I've created it.
OK, that makes sense.
>> I feel like we're now starting to drill down into implementation details.
>> I believe I have a good enough understanding now to put together a
>> proposal, so I'm going to begin working on that, but I'd like to keep
>> this thread going as well.
>>
> Read carefully how POST is different from PUT. I forget the details,
> but I'm sure it will become more clear...
I actually just took a look at the HTTP spec:
"The fundamental difference between the POST and PUT requests is reflected
in the different meaning of the Request-URI. The URI in a POST request
identifies the resource that will handle the enclosed entity. That resource
might be a data-accepting process, a gateway to some other protocol, or a
separate entity that accepts annotations. In contrast, the URI in a PUT
request identifies the entity enclosed with the request -- the user agent
knows what URI is intended and the server MUST NOT attempt to apply the
request to some other resource. If the server desires that the request be
applied to a different URI, it MUST send a 301 (Moved Permanently)
response; the user agent MAY then make its own decision regarding whether
or not to redirect the request."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
So POST can create or update a resource anywhere, and PUT must create a
resource at the exact location you tell it.
One question on writing up this proposal: do you have a template that you
encourage GSoC applicants to use? If not, I'll just write up a basic
proposal, formatted in Latex, and submit it as a PDF. Please let me know if
that will work.
Thanks,
Jake
|
|
|
| Re: [emf-dev] exposing Ecore models via web services [message #428794 is a reply to message #428793] |
Mon, 30 March 2009 18:04 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050201020101020509080000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Jake,
I've not been following the GSoC stuff as closely as I should (for
personal reasons). I'm not sure the best form for a submission...
Jacob Beard wrote:
> Hi Ed,
>
> Thanks for the quick response.
>
>
>>> It seems like, because you're overloading the HTTP method, there would
>>> then need to be some canonical way of encoding Create and Update
>>> operations in PUT data, so as to differentiate them. Please let me know
>>> about this.
>>>
>>>
>> I think of it the same way as if I write to a file. I just write to
>> it. If the file already existed, then I overwrite it. If not, then
>> I've created it.
>>
>
> OK, that makes sense.
>
>
>>> I feel like we're now starting to drill down into implementation details.
>>> I believe I have a good enough understanding now to put together a
>>> proposal, so I'm going to begin working on that, but I'd like to keep
>>> this thread going as well.
>>>
>>>
>> Read carefully how POST is different from PUT. I forget the details,
>> but I'm sure it will become more clear...
>>
>
> I actually just took a look at the HTTP spec:
>
> "The fundamental difference between the POST and PUT requests is reflected
> in the different meaning of the Request-URI. The URI in a POST request
> identifies the resource that will handle the enclosed entity. That resource
> might be a data-accepting process, a gateway to some other protocol, or a
> separate entity that accepts annotations. In contrast, the URI in a PUT
> request identifies the entity enclosed with the request -- the user agent
> knows what URI is intended and the server MUST NOT attempt to apply the
> request to some other resource. If the server desires that the request be
> applied to a different URI, it MUST send a 301 (Moved Permanently)
> response; the user agent MAY then make its own decision regarding whether
> or not to redirect the request."
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>
> So POST can create or update a resource anywhere, and PUT must create a
> resource at the exact location you tell it.
>
> One question on writing up this proposal: do you have a template that you
> encourage GSoC applicants to use? If not, I'll just write up a basic
> proposal, formatted in Latex, and submit it as a PDF. Please let me know if
> that will work.
>
> Thanks,
>
> Jake
>
--------------050201020101020509080000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jake,<br>
<br>
I've not been following the GSoC stuff as closely as I should (for
personal reasons). I'm not sure the best form for a submission...<br>
<br>
<br>
Jacob Beard wrote:
<blockquote cite="mid:gqr0s9$81h$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
Thanks for the quick response.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">It seems like, because you're overloading the HTTP method, there would
then need to be some canonical way of encoding Create and Update
operations in PUT data, so as to differentiate them. Please let me know
about this.
</pre>
</blockquote>
<pre wrap="">I think of it the same way as if I write to a file. I just write to
it. If the file already existed, then I overwrite it. If not, then
I've created it.
</pre>
</blockquote>
<pre wrap=""><!---->
OK, that makes sense.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I feel like we're now starting to drill down into implementation details.
I believe I have a good enough understanding now to put together a
proposal, so I'm going to begin working on that, but I'd like to keep
this thread going as well.
</pre>
</blockquote>
<pre wrap="">Read carefully how POST is different from PUT. I forget the details,
but I'm sure it will become more clear...
</pre>
</blockquote>
<pre wrap=""><!---->
I actually just took a look at the HTTP spec:
"The fundamental difference between the POST and PUT requests is reflected
in the different meaning of the Request-URI. The URI in a POST request
identifies the resource that will handle the enclosed entity. That resource
might be a data-accepting process, a gateway to some other protocol, or a
separate entity that accepts annotations. In contrast, the URI in a PUT
request identifies the entity enclosed with the request -- the user agent
knows what URI is intended and the server MUST NOT attempt to apply the
request to some other resource. If the server desires that the request be
applied to a different URI, it MUST send a 301 (Moved Permanently)
response; the user agent MAY then make its own decision regarding whether
or not to redirect the request."
<a class="moz-txt-link-freetext" href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html">http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html</a>
So POST can create or update a resource anywhere, and PUT must create a
resource at the exact location you tell it.
One question on writing up this proposal: do you have a template that you
encourage GSoC applicants to use? If not, I'll just write up a basic
proposal, formatted in Latex, and submit it as a PDF. Please let me know if
that will work.
Thanks,
Jake
</pre>
</blockquote>
</body>
</html>
--------------050201020101020509080000--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [emf-dev] exposing Ecore models via web services [message #507869 is a reply to message #428794] |
Thu, 14 January 2010 22:42 |
Jake
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
Hi all,
I just wanted to let the list know that I've revived this project. While
my application for Google Summer of Code 2009 was accepted, the project
did not progress to a point where I was able to experiment with exposing
EMF models to the browser via RESTful APIs. However, I am currently
taking a project-oriented Master's course in software architecture, and
so I, along with another student, will have the opportunity to focus
exclusively on the issue of binding data between and EMF model instances
hosted on a web server, and the browser client. I'll probably start a
new thread on the subject soon with a more formal description of the
project and our goals.
Thanks,
Jake
Ed Merks wrote:
> Jake,
>
> I've not been following the GSoC stuff as closely as I should (for
> personal reasons). I'm not sure the best form for a submission...
>
>
> Jacob Beard wrote:
>> Hi Ed,
>>
>> Thanks for the quick response.
>>
>>
>>>> It seems like, because you're overloading the HTTP method, there would
>>>> then need to be some canonical way of encoding Create and Update
>>>> operations in PUT data, so as to differentiate them. Please let me know
>>>> about this.
>>>>
>>>>
>>> I think of it the same way as if I write to a file. I just write to
>>> it. If the file already existed, then I overwrite it. If not, then
>>> I've created it.
>>>
>>
>> OK, that makes sense.
>>
>>
>>>> I feel like we're now starting to drill down into implementation details.
>>>> I believe I have a good enough understanding now to put together a
>>>> proposal, so I'm going to begin working on that, but I'd like to keep
>>>> this thread going as well.
>>>>
>>>>
>>> Read carefully how POST is different from PUT. I forget the details,
>>> but I'm sure it will become more clear...
>>>
>>
>> I actually just took a look at the HTTP spec:
>>
>> "The fundamental difference between the POST and PUT requests is reflected
>> in the different meaning of the Request-URI. The URI in a POST request
>> identifies the resource that will handle the enclosed entity. That resource
>> might be a data-accepting process, a gateway to some other protocol, or a
>> separate entity that accepts annotations. In contrast, the URI in a PUT
>> request identifies the entity enclosed with the request -- the user agent
>> knows what URI is intended and the server MUST NOT attempt to apply the
>> request to some other resource. If the server desires that the request be
>> applied to a different URI, it MUST send a 301 (Moved Permanently)
>> response; the user agent MAY then make its own decision regarding whether
>> or not to redirect the request."
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>>
>> So POST can create or update a resource anywhere, and PUT must create a
>> resource at the exact location you tell it.
>>
>> One question on writing up this proposal: do you have a template that you
>> encourage GSoC applicants to use? If not, I'll just write up a basic
>> proposal, formatted in Latex, and submit it as a PDF. Please let me know if
>> that will work.
>>
>> Thanks,
>>
>> Jake
>>
|
|
|
| Re: [emf-dev] exposing Ecore models via web services [message #507893 is a reply to message #507869] |
Fri, 15 January 2010 01:17 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Jacob,
That sounds cool. I look forward to that.
Jacob Beard wrote:
> Hi all,
>
> I just wanted to let the list know that I've revived this project.
> While my application for Google Summer of Code 2009 was accepted, the
> project did not progress to a point where I was able to experiment
> with exposing EMF models to the browser via RESTful APIs. However, I
> am currently taking a project-oriented Master's course in software
> architecture, and so I, along with another student, will have the
> opportunity to focus exclusively on the issue of binding data between
> and EMF model instances hosted on a web server, and the browser
> client. I'll probably start a new thread on the subject soon with a
> more formal description of the project and our goals.
>
> Thanks,
>
> Jake
>
> Ed Merks wrote:
>> Jake,
>>
>> I've not been following the GSoC stuff as closely as I should (for
>> personal reasons). I'm not sure the best form for a submission...
>>
>>
>> Jacob Beard wrote:
>>> Hi Ed,
>>>
>>> Thanks for the quick response.
>>>
>>>
>>>>> It seems like, because you're overloading the HTTP method, there
>>>>> would
>>>>> then need to be some canonical way of encoding Create and Update
>>>>> operations in PUT data, so as to differentiate them. Please let me
>>>>> know
>>>>> about this.
>>>>>
>>>> I think of it the same way as if I write to a file. I just write to
>>>> it. If the file already existed, then I overwrite it. If not, then
>>>> I've created it.
>>>>
>>>
>>> OK, that makes sense.
>>>
>>>
>>>>> I feel like we're now starting to drill down into implementation
>>>>> details.
>>>>> I believe I have a good enough understanding now to put together a
>>>>> proposal, so I'm going to begin working on that, but I'd like to keep
>>>>> this thread going as well.
>>>>>
>>>> Read carefully how POST is different from PUT. I forget the details,
>>>> but I'm sure it will become more clear...
>>>>
>>>
>>> I actually just took a look at the HTTP spec:
>>>
>>> "The fundamental difference between the POST and PUT requests is
>>> reflected
>>> in the different meaning of the Request-URI. The URI in a POST request
>>> identifies the resource that will handle the enclosed entity. That
>>> resource
>>> might be a data-accepting process, a gateway to some other protocol,
>>> or a
>>> separate entity that accepts annotations. In contrast, the URI in a PUT
>>> request identifies the entity enclosed with the request -- the user
>>> agent
>>> knows what URI is intended and the server MUST NOT attempt to apply the
>>> request to some other resource. If the server desires that the
>>> request be
>>> applied to a different URI, it MUST send a 301 (Moved Permanently)
>>> response; the user agent MAY then make its own decision regarding
>>> whether
>>> or not to redirect the request."
>>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>>>
>>> So POST can create or update a resource anywhere, and PUT must create a
>>> resource at the exact location you tell it.
>>>
>>> One question on writing up this proposal: do you have a template
>>> that you
>>> encourage GSoC applicants to use? If not, I'll just write up a basic
>>> proposal, formatted in Latex, and submit it as a PDF. Please let me
>>> know if
>>> that will work.
>>>
>>> Thanks,
>>>
>>> Jake
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 11:22:39 GMT 2024
Powered by FUDForum. Page generated in 0.03853 seconds |
] 
Search
Help
Register
Login
Home
