[windup-dev] REST <- graph api?

[Brad Davis]

 patternfly for the UI?

Thanks,
Brad Davis
Director of FSI Solutions, Red Hat
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com 

> On Jul 1, 2016, at 9:45 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> 
> +1 to getting this straight before getting deep into Windup 3.
> 
> To those 4 approaches in the document, I would suggest one more.
> Kind of a hybrid.
> 
> The point of this, I assume, is to reduce the repetitive patterns in the 
> chain: graph -> Java Model -> Java service -> DTO -> REST -> JSON -> TS 
> service -> JS model -> Angular 2.
> So we should reuse the information already contained somewhere.
> 
> The most frequent scenarios I can forsee are:
> 
> 1) Query by property, get the resulting objects, optionally with some 
> nested objects.
> 2) Start with a set of objects, query some other objects in some 
> relation to those.
> 3) Start with one object and get a tree starting with that object, based 
> on some recursive relation.
> 4) More complex queries.
> 
> I suggest to stick with something simple, so for 4), we could have 
> custom services.
> 
> For 1) 2) 3), we could have a simple "URL to objects" schema, not trying 
> to be a generic query tool.
> It could reuse the Models.
> Examples (made up):
> 1) /graph/File{path=...}!out:fileToProject,getClassifications,:...     
> -- File objects with given properties with objects from relations 
> defined behind ! attached to it.
> 2) /graph/Project/id=[1,2,3]/out:projectToFile/{path=...}
> 3a) /graph/Project/id=1//in:parent!out:fileToProject -- will query 
> what's under that relation
> 3b) /graph/Project/id=1//in:parent!getProjects  -- will use the method 
> to attach the objects.
> 
> Maybe it's quite similar to what's proposed in the doc under 4, only a 
> bit more type oriented, and also more use-case oriented and less generic.
> 
> my2c.
> Ondra
> 
> 
>> On 1.7.2016 23:28, Jess Sightler wrote:
>> I don't think we ever discussed this in the Thursday meeting. My mic
>> problems probably didn't help with that (sorry about that). I have
>> started a document to discuss a few different approaches to building
>> REST services for the web application.
>> 
>> Keep in mind the following high level requirements:
>> 
>>   - Support querying of data easily for both the global configuration
>> graph (eg, projects, groups etc) as well as for the individual graphs
>> 
>>   - Support persisting new data to the graph for the configuration graph
>> 
>>   - Support easy marshalling to/from ECMAScript objects
>> 
>> 
>> I have added these to the document as well:
>> 
>> https://docs.google.com/document/d/1jJz-NuTI00A7VcP7K58Gv6sWGyC8CuMsc5MVldRrc6Y/edit#heading=h.9hob5uguvtqc
>> 
>> 
>> Feel free to add your thoughts as well.
>> 
>> 
>> Thanks,
>> 
>> Jess
>> 
>> 
>> 
>>> On 06/26/2016 07:26 PM, Ondrej Zizka wrote:
>>> Hi devs,
>>> 
>>> How about creating a layer that would query the graph based on a REST URL?
>>> I.e. instead of creating a REST endpoint for each service, we could do
>>> something like
>>> 
>>> localhost//windup/rest/graph/ProjectModel/id-48984/out-projectTofile/with-...
>>> 
>>> Or some subset of Gremlin perhaps...
>>> Just an idea.
>>> 
>>> Ondra
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> 
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20160702/bff2b399/attachment.html