API filters and nested statements
163 views
Skip to first unread message
Justin Halsall
May 15, 2015, 10:28:30 AM5/15/15
to api-...@googlegroups.com
Hi,
I have been searching around for a nice API syntax to do filters with nested statements.
In my search if found OData. It seems to support nested statements and much much more.
Somewhat to complex and extensive if you ask me. Does anyone know of any nice alternatives to OData?
Preferably something that has some node.js libraries for it, but its not a deal breaker if it doesn't.
Cheers,
Justin
Chris Mullins
May 15, 2015, 1:32:14 PM5/15/15
to api-...@googlegroups.com
I've spent quite a bit of time dealing with ODataV4 over the past year or so.
Let me share how the conversations (including my own) have generally gone:
1. We need to do X. OData has support for that, but it's frightfully complex and overkill for what I need.
2. Instead of OData, we're going to do something much simpler that meets our use case.
3. <Some time Later>
4. We had to add a few more features to our solution. Things are looking a bit sloppy now.
5. <Some time later>
6. We're still adding features, ones we originally didn't think we would need. Everything is starting to feel like a hack, and we're spending more time on our platform components than our actual software.
7. <Some time later>
8. Screw it. We're dropping what we did and just using OData. It turns out we need a big percentage of it's features and having the flight path in front of us for future growth is awesome.
In my day job, I've spent a fair bit of time coming up with "Simpler" versions of many of the Odata patterns and semantics just to provide a quick on-boarding process yet still provide room for growth should the project(s) need it down the lime. I can't share any of that at this time, unfortunately.
This doesn't answer your question, and I'm perhaps a bit biased in my answers as I know the OData folks quite well, but the above is a pattern of behavior I've seen again and again.
Cheers,
Chris
Kin Lane
May 15, 2015, 1:58:30 PM5/15/15
to api-...@googlegroups.com
Hey Chris,
I think you just described the hard work that goes into properly designing an API, whether its the surface area, request, response data models, to the hypermedia structure and flow.
I feel people have a shortage of time, and knowledge to tackle properly, and opt for the pain and suffering over time, rather than up front in the learning and design process.
Do you mind if I publish an excerpt of your story on my blog?
--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.
Chris Mullins
May 15, 2015, 3:16:06 PM5/15/15
to api-...@googlegroups.com
Go ahead. :-)
My point is much in agreement with you: I believe folks should focus on their value-add.
The platform level mechanics of how paging works, or how sorting works, or the syntax around filter statements, are generally not (in my opinion) something they should have to worry about. Time spent on the low-level mechanics is time not spent building your API, and time not spent improving your product. The opportunity cost of that is huge! The flip side of this is that each time a developer comes up with a new mechanism for paging, filtering, or sorting (etc, etc), is puts the burden on customers to learn yet another syntax. Ick.
For all it's faults ODataV4 is very well thought out and highly capable. The tooling ecosystem around it, in terms of both producing and consuming OData APIs is also growing nicely. Now I just need Swagger and OData to be compatible with each other and the world will become a better place... :-)
Cheers,
Chris
Kin Lane
May 15, 2015, 3:37:45 PM5/15/15
to api-...@googlegroups.com
Mike Amundsen and I were just talking about the need for more microtooling around media types, data formats, and api definitions, to not just help people implement, but also learn.
Would like to see more in the OData realm.... ;-) abstract away complexity while learning, make easier to reverse engineer, etc.
Message has been deleted
Victor Olex
Jun 4, 2015, 3:56:45 PM6/4/15
to api-...@googlegroups.com
For /db we opted for a graph facade over relational data, which is cleaner than querying nested results with some nested json-filter. Our API allows for filtering at each node of the graph and to continue to the next node. Here's an example on a database for an online music store:
List all music genres:
Filter that for Classical music, and traverse to related Track records:
Now lookup related invoices but only the ones with a total amount over $10
For the same in JSON format, append .json to the URL or send application/json Accept header with your request:
Lastly, give me that with related data Customer and InvoiceLine data inlined in a nested structure:
Pretty good, no?
More about /db at http://www.slashdb.com
Ralf Handl
May 18, 2016, 8:33:17 AM5/18/16
to API Craft
The OData Technical Committee is currently working on defining an OpenAPI (fka Swagger) representation for OData $metadata.
Examples can be found here: https://github.com/ralfhandl/odata
The work-in-progress specification (caution: rather technical language, not as appealing as the examples :-) can be found here: https://www.oasis-open.org/committees/download.php/57858/odata-json-csdl-v4.0-wd02-2016-04-01.docx
Feedback is highly welcome
Always eager to make the world a better place :-)
Thanks
Ralf
Reply all
Reply to author
Forward
0 new messages