Community
Participate
Working Groups
There is a need to shape resources returned by our RESTful API based on specific need. We could limit the number of attributes or inline other resources instead of using resource locations. For instance: GET on /gitapi/tag/... returns objects like this: { "CommitLocation": ... "FullName": ... "LocalTimeStamp": 1326237585000, "Location": ..., "Name": "v20120110-2319", "Type": "Tag" }, The flat-layout repo page needs the commit resource inlined in the tag representation (bug 368425): { "Commit": { ... } "FullName": ... "LocalTimeStamp": 1326237585000, "Location": ..., "Name": "v20120110-2319", "Type": "Tag" } I think we need some kind of a template how to parameterize URIs to get resources in some required shape.
I would think this is simple traditional key/value query parameters on the resource, like we do ?depth=1 on the file API.
Git resources are heterogeneous comparing to files. Each git response has different structure, so ?depth=1 won't work. What first came to my mind were two params: "expand" and "collapse". They would work like this: Assume A and B: => GET /A <= { aProperty : "...", BLocation : "/B/...", CLocation : "/C/..." } => GET /B <= { bProperty : "...", DLocation : "/D/..." } => GET /C <= { cProperty : "...", DLocation : "/D/..." } then with the "expand" param we could decide which location should be "expanded" in the response: => GET /A?expand=B <= { aProperty : "...", B : { bProperty : "..." DLocation : "/D/...", }, CLocation : "/C/..." } => GET /A?expand=B,C <= { aProperty : "...", B : { bProperty : "..." DLocation : "/D/...", }, C : { cProperty : "...", DLocation : "/D/..." } } using "collapse" would tell the server which nodes keep "collapsed" and "expand" the rest => GET /A?collapse=C <= { aProperty : "...", B : { bProperty : "..." DLocation : "/D/...", }, CLocation : "/C/..." } This should also allow nesting like this: => GET /A?... <haven't thought about the URI yet> <= { aProperty : "...", B : { bProperty : "..." D : { dProperty : "..." }, }, CLocation : "/C/..." }
(In reply to comment #2) > This should also allow nesting like this: > > => GET /A?... <haven't thought about the URI yet> Reading how GData tries to deal with this sounds like a good idea: http://code.google.com/apis/gdata/docs/2.0/reference.html#PartialResponse
There is also an OSLC spec for specifying properties to be included in the response: http://open-services.net/bin/view/Main/OSLCCoreSpecQuery?sortcol=table;up=#oslc_select
Updated orbit.map and server's feature with new dependency on ANTLR : http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=eb072fb4b5b903d55c05b26d80dfb20be9dc1e62. Available in builds >= I20120514-2230, any of them should be used as a target platform.
Did you enter a CQ for Antrl? We are long past the CQ deadline for June release but it is possible it will be accepted. Can you explain what Antlr is being used for here - it seems like overkill if it is just parsing URL arguments.
(In reply to comment #6) > Did you enter a CQ for Antrl? We are long past the CQ deadline for June release > but it is possible it will be accepted. The CQ I found on Orbit download page [1] is CQ 4865. I assumed if the lib is in the repo it can be freely used. To I need to file a new CQ for using ANTLR in Orion? I guess if that's required I could easily piggyback on that CQ. > Can you explain what Antlr is being used > for here - it seems like overkill if it is just parsing URL arguments. It is used for parsing the URL param representing selection query. It may seem like overkill at first, but: * even now the query can have different forms from with simple comma separated lists of properties ie "A,B,C" to lists with nested properties and wildcards ie "A,B{*},C{C1,D{D1,D2}}" * in the future we plan to add negations so excluding specific properties would be easier * we also plan to add support for predefined, named sets of properties to be used instead of longer lists ie A,B{$name} not A,B{B1,B2,B4} I agree that the grammar is now quite simple, but I would probably spend the same amount of time implementing my own parser for nested properties. Moreover, given the future plans adding few extra rules to the grammar should be easier than maintaining the homegrown parser. And last, but not least in the eventuality of supporting the OSLC syntax for the selection having their grammar in hand we would be halfway done. [1] http://download.eclipse.org/tools/orbit/downloads/drops/S20120509234235/
Server/Core changes + initial adoption of git resources from o.e.orion.server.git.objects.* pushed as http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=6d548a9cb873e04ba6baa7d6bbc6e81c6d54540c (yesterday).
Added default resource shapes for git resources. #toJSON methods delegate now object serialization to JSONSerializer with the default resource shape. See http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=29ce754cf0af4c74a56f008910c3825220419a1e The next step would be to handle custom selection queries and use them to serialize git objects.
Hey guys, This looks like you're adding batch request support to the server. That's fine as I understand it might be critical for performance but I want to understand how/if that impacts the client service api. In particular I'm concerned that we will leak the details of request batching into the client-side apis. Can you describe it a little or point me at another relevant bug.
Created attachment 215710 [details] mylyn/context/zip
Although it would be nice if we could get rid of it, I have entered this CQ for Orion to use Antlr: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=6534
I talked to Simon about API being exposed by this change. It seems we agreed that each resource may have a set of predefined shapes. Each shape defines what properties/fields are part of the (JSON) response. For this we indeed do not need Antlr.
Created attachment 216457 [details] Patch removing the ANTLR dependency
Created attachment 216639 [details] Patch removing ANTLR dependency Removed a dummy ResourceShapeDescription annotation introduced in the previous patch
(In reply to comment #15) > Created attachment 216639 [details] > Patch removing ANTLR dependency > > Removed a dummy ResourceShapeDescription annotation introduced in the previous > patch Looks good. We need to open a bug for further work i.e. being able to use shapes other than the default one.
(In reply to comment #14) > Created attachment 216457 [details] (In reply to comment #15) > Created attachment 216639 [details] Both patches applied as http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=4220523b2b4466ae149ef336be9a5fd4fabe5756 The ANTLR dep is gone. The code still contains a bunch of TODOs, but the work can be continued on separate bugs like bug 381350 as Szymon suggested in the previous comment.
