| Time |
S |
Nick |
Message |
| 00:45 |
|
|
wavded joined #rest |
| 00:56 |
|
|
robo7 joined #rest |
| 01:02 |
|
|
bluezone joined #rest |
| 01:32 |
|
|
robo7_ joined #rest |
| 01:34 |
|
|
robo7__ joined #rest |
| 05:32 |
|
|
baweaver joined #rest |
| 06:06 |
|
|
profsimm joined #rest |
| 06:07 |
|
profsimm |
You know, I have long been working on this idea of a REST-like system for editing and viewing data, but it's not compatible with idioms popularly associated with REST these days. For example, it can be tunneled through HTTP but it doesn't map to it 100% |
| 06:07 |
|
profsimm |
But at the same time it feels more REST-like than any HTTP REST system I've seen |
| 06:59 |
|
|
baweaver joined #rest |
| 07:50 |
|
profsimm |
Soo anyone here |
| 12:37 |
|
|
timg___ joined #rest |
| 12:58 |
|
pdurbin |
profsimm: we're here |
| 12:59 |
|
profsimm |
pdurbin: I was wondering is there any interest in REST APIs which aren't the typical HTTP CRUD stuff. |
| 12:59 |
|
profsimm |
pdurbin: I'm working on a spec for a REST API which allows an admin panel to be created automatically from an API, but it's not your run-of-the-mill HTTP stuff |
| 13:00 |
|
profsimm |
In a way it's closer to the dream of "automatic API client" than anything I've seen |
| 13:02 |
|
pdurbin |
profsimm: can you please link to your spec? |
| 13:05 |
|
|
timg___ joined #rest |
| 13:14 |
|
profsimm |
pdurbin: it's not public, I'm still working on it. I was wondering if it rings a bell, can someone point to similar standards, and whether calling it REST despite it's not strictly HTTP or "mainstream REST" is appropriate |
| 13:14 |
|
|
mezod joined #rest |
| 13:19 |
|
pdurbin |
profsimm: how is it different than https://en.wikipedia.org/wiki/HATEOAS ? |
| 13:20 |
|
profsimm |
pdurbin: HATEOAS is a bit rudimentary and some of its features have no practical implications |
| 13:21 |
|
profsimm |
pdurbin: it's also quite verbose, I don't pass meta information in every response. |
| 13:21 |
|
pdurbin |
ok |
| 13:21 |
|
profsimm |
pdurbin: I do it when I get a "describe" call which specifically describes the structure of an API, or when someone wants results with meta info. |
| 13:21 |
|
pdurbin |
cool |
| 13:22 |
|
profsimm |
pdurbin: my original problem was... how to create an efficient admin where people can enter data quickly, and not resource by resource, but also atomically update a set of resources. |
| 13:23 |
|
profsimm |
pdurbin: for example... query a set of resources, a subset of their fields, order them by some criteria, and the results are editable in the admin and have a single save button: when you save, either all save, or none, and if none, you get aggregate errors for all you wanted to save |
| 13:23 |
|
pdurbin |
sounds like a somewhat common problem |
| 13:23 |
|
profsimm |
pdurbin: it is quite common, and it may be poor research on my side, but I don't see solutions covering the whole problem. |
| 13:25 |
|
pdurbin |
profsimm: I wonder how your admin compares to the one that ships with Django. |
| 13:25 |
|
profsimm |
pdurbin: which feature of django's admin panel are we talking about |
| 13:26 |
|
profsimm |
pdurbin: I see, yeah I see some similarities. |
| 13:27 |
|
profsimm |
pdurbin: one immediate difference, I think, is mine is API based. The admin may be Python, the model may be Java |
| 13:27 |
|
profsimm |
pdurbin: the meta info is not language specific |
| 13:28 |
|
profsimm |
pdurbin: another is, I'm not sure if Django supports "deep" data structures. |
| 13:28 |
|
profsimm |
pdurbin: as in fields which are themselves entities, which contain entities etc. |
| 13:29 |
|
profsimm |
Maybe I'm wrong. |
| 13:32 |
|
pdurbin |
profsimm: you're using JPA? |
| 13:32 |
|
profsimm |
pdurbin: no |
| 13:33 |
|
profsimm |
pdurbin: Java was an example, my point was I can have models in one set of language, dmin in another set |
| 13:33 |
|
profsimm |
admin* |
| 13:33 |
|
profsimm |
Its not a big monolith. |
| 13:33 |
|
profsimm |
It's connected via said API |
| 13:35 |
|
pdurbin |
profsimm: so you could have either postgres or mongodb in the back end. you're flexible |
| 13:36 |
|
profsimm |
pdurbin: sarcasm detected :P |
| 13:36 |
|
profsimm |
pdurbin: but the data source is irrelevant, right. |
| 13:36 |
|
profsimm |
pdurbin: you implement the spec and it works. |
| 13:37 |
|
profsimm |
pdurbin: things is, it's easy to create a generic spec that's bad. |
| 13:37 |
|
profsimm |
pdurbin: it's hard to create one that preserves performance and flexibility, yet remains technology neutral. |
| 13:38 |
|
|
whartung_ joined #rest |
| 13:41 |
|
|
Davey_ joined #rest |
| 13:41 |
|
|
Davey_ joined #rest |
| 13:42 |
|
profsimm |
pdurbin: but there are some common data structures you can model interactions around, from good old comp-sci: maps, lists, tuples, sets... |
| 13:42 |
|
pdurbin |
profsimm: sorry, not trying to by sarcastic. just curious |
| 13:43 |
|
profsimm |
pdurbin: and I have to say SQL has got some quite good ideas about how to interact with data |
| 13:43 |
|
profsimm |
FROM set of entities SELECT fields WHERE condition ORDER BY condition |
| 13:43 |
|
profsimm |
Those are quite generic clauses which can be actually also SQL neutral. |
| 13:43 |
|
pdurbin |
sure. I'm not a SQL hater |
| 13:44 |
|
profsimm |
Facebook is taking a hint with that in their GraphQL. |
| 13:44 |
|
profsimm |
GraphQL can be powered by anything, it's not a database itself, it's just an API format. |
| 13:44 |
|
profsimm |
Mine has some similarities to it, accidental, or maybe not, because I feel this keeps getting reinvented. |
| 13:46 |
|
pdurbin |
could be |
| 13:46 |
|
profsimm |
But point is... is it REST. I feel it is, in the spirit of the paper. |
| 13:46 |
|
profsimm |
But it's not even HTTP specific. |
| 13:47 |
|
profsimm |
HTTP is just one interface, but I don't use links for references. |
| 13:47 |
|
profsimm |
Because they don't provide the semantics I need |
| 13:49 |
|
pdurbin |
profsimm: at the end of the day, you're trying to build a web gui, right? that's the "admin" |
| 13:58 |
|
profsimm |
pdurbin: web gui is one use of this, but it can also be a native UI fed from the same metadata. And not just GUI but tooling. |
| 13:58 |
|
profsimm |
pdurbin: but yeah |
| 13:59 |
|
|
rickharrison joined #rest |
| 14:05 |
|
|
ChrisAnn joined #rest |
| 14:08 |
|
|
StatelessCat joined #rest |
| 14:18 |
|
pdurbin |
profsimm: I guess you could make a desktop or even mobile admin app some day |
| 14:18 |
|
profsimm |
pdurbin: that's the goal, to keep things isolated and extensible, not platform-specific. Has pros and cons, but... IMHO, mostly pros. |
| 14:19 |
|
profsimm |
pdurbin: it require less thinking to make a monolith, but thinking leads to unexpected insights that make everything better sometimes |
| 14:20 |
|
pdurbin |
sure |
| 14:21 |
|
pdurbin |
profsimm: I'm just thinking that I would push the Django admin as far as I could first and see what I learn, see where the shortcomings are. |
| 14:22 |
|
profsimm |
pdurbin: I did explore it just now and I hit the limits quite fast. 1) The models are local and SQL-only 2) Nesting is limited 3) Manipulating transformed results is very limited (basically you can sort a table of rows and that's it) |
| 14:22 |
|
profsimm |
pdurbin: it is sort of the right idea |
| 14:23 |
|
profsimm |
pdurbin: but implemented in a monolithic Django-specific SQL-specific way, which I see a lot TBH |
| 14:24 |
|
pdurbin |
profsimm: maybe you should make ask if Django has any plans to go in the direction you'd like with your admin ideas. |
| 14:24 |
|
profsimm |
pdurbin: in my case the point is to implement an encapsulated API first, then point an admin to it, and ... it works. |
| 14:24 |
|
profsimm |
pdurbin: I doubt it. |
| 14:25 |
|
pdurbin |
whoops, I was going to say "make some noise in a Django channel" :) |
| 14:25 |
|
profsimm |
pdurbin: it'd be quite the shift, most of those products tend to stick to SQL CRUD. |
| 14:25 |
|
profsimm |
I mean in long term I definitely think this is the way. |
| 14:25 |
|
pdurbin |
so what else is out there that's similar to the Django admin? I guess there's https://www.phpmyadmin.net |
| 14:26 |
|
profsimm |
Headless Drupal, GraphQL, WordPress is also moving to REST APIs |
| 14:26 |
|
profsimm |
and so on |
| 14:26 |
|
profsimm |
People are kind of waking up to the approach but |
| 14:26 |
|
profsimm |
Very slowly. |
| 14:26 |
|
profsimm |
pdurbin: that one is outright a database editor, not an admin for an API so |
| 14:26 |
|
pdurbin |
yeah |
| 14:27 |
|
profsimm |
I'll figure it out. Thanks for the chat. |
| 14:28 |
|
pdurbin |
profsimm: oh sure. when you have something to link to, please do |
| 14:29 |
|
pdurbin |
profsimm: meanwhile, I'm asking the sysadmins who code about it: http://irclog.perlgeek.de/crimsonfu/2015-12-06 :) |
| 14:30 |
|
profsimm |
Fun :) |
| 14:44 |
|
|
ramsey joined #rest |
| 15:19 |
|
|
timg___ joined #rest |
| 15:22 |
|
|
timg___ joined #rest |
| 16:10 |
|
|
simonv3 joined #rest |
| 17:05 |
|
|
Coldblackice joined #rest |
| 17:34 |
|
|
mezod joined #rest |
| 17:42 |
|
|
philbot joined #rest |
| 17:42 |
|
|
Topic for #rest is now #rest REpresentational State Transfer | logs: http://irclog.greptilian.com/rest/today | http://tech.groups.yahoo.com/group/rest-discuss | http://code.google.com/p/implementing-rest/ | http://en.wikipedia.org/wiki/Representational_State_Transfer |
| 17:46 |
|
|
timg___ joined #rest |
| 18:13 |
|
|
profsimm left #rest |
| 19:11 |
|
|
fuzzyhorns joined #rest |
| 19:12 |
|
|
mooncup joined #rest |
| 19:12 |
|
|
mooncup joined #rest |
| 19:45 |
|
|
fuzzyhorns joined #rest |
| 20:17 |
|
|
fuzzyhorns joined #rest |
| 20:33 |
|
|
mezod joined #rest |
| 20:36 |
|
|
fuzzyhorns joined #rest |
| 21:40 |
|
|
fuzzyhorns joined #rest |
| 21:52 |
|
|
timg___ joined #rest |
| 22:41 |
|
|
fuzzyhorns joined #rest |
| 23:35 |
|
|
simonv3 joined #rest |
