| Time |
S |
Nick |
Message |
| 00:08 |
|
|
ruibritopt joined #rest |
| 00:40 |
|
|
shrink0r joined #rest |
| 00:41 |
|
|
shrink0r_ joined #rest |
| 00:45 |
|
|
talios joined #rest |
| 01:24 |
|
|
shrink0r joined #rest |
| 01:28 |
|
|
ralphschindler joined #rest |
| 01:28 |
|
|
shrink0r joined #rest |
| 03:30 |
|
|
tr3online joined #rest |
| 03:57 |
|
|
shrink0r_ joined #rest |
| 03:59 |
|
|
shrink0r joined #rest |
| 04:02 |
|
|
lemur joined #rest |
| 04:42 |
|
|
lemur_ joined #rest |
| 04:59 |
|
|
lemur joined #rest |
| 05:08 |
|
|
shrink0r_ joined #rest |
| 05:09 |
|
|
shrink0r joined #rest |
| 05:33 |
|
|
tr3online joined #rest |
| 05:40 |
|
|
shrink0r_ joined #rest |
| 05:42 |
|
|
shrink0r joined #rest |
| 05:43 |
|
|
shrink0r_ joined #rest |
| 05:50 |
|
|
talios joined #rest |
| 07:16 |
|
|
proteusguy joined #rest |
| 07:52 |
|
|
lemur joined #rest |
| 07:56 |
|
|
adaro joined #rest |
| 08:29 |
|
|
adaro joined #rest |
| 08:48 |
|
|
azer_ joined #rest |
| 09:19 |
|
|
tr3online joined #rest |
| 09:21 |
|
|
tr3online joined #rest |
| 09:21 |
|
|
tr3online joined #rest |
| 09:29 |
|
|
shrink0r joined #rest |
| 09:32 |
|
|
talios joined #rest |
| 10:07 |
|
|
Left_Turn joined #rest |
| 10:27 |
|
|
azer_ joined #rest |
| 10:29 |
|
|
warehouse13 joined #rest |
| 11:05 |
|
|
graste joined #rest |
| 11:23 |
|
|
tr3online joined #rest |
| 11:23 |
|
|
interop_madness joined #rest |
| 11:41 |
|
|
mezod joined #rest |
| 11:46 |
|
|
Jefffrey joined #rest |
| 12:24 |
|
|
tr3online joined #rest |
| 12:32 |
|
|
michaelis joined #rest |
| 12:32 |
|
michaelis |
Hi. I have installed a REST client in Firefox. Is there any way I can test it? |
| 12:44 |
|
|
azer_ joined #rest |
| 12:44 |
|
michaelis |
Does anyone know of a RESTful service online so that I can try out my application? |
| 13:14 |
|
|
azer_ joined #rest |
| 13:17 |
|
|
azer_ joined #rest |
| 13:38 |
|
|
nkoza joined #rest |
| 13:52 |
|
pdurbin |
michaelis: https://apitest.dataverse.org |
| 13:54 |
|
pdurbin |
of course, I doubt that server of mine is RESTful. probably people would call it RPC :( |
| 13:54 |
|
pdurbin |
No one here has ever linked me to a truly RESTful service. I'm starting to doubt if they exist. |
| 13:55 |
|
trygvis |
hehe |
| 13:55 |
|
trygvis |
I haven't done much open work so it's hard to link to anything useful |
| 13:56 |
|
trygvis |
and I think heroku has shut down my collection+json instance |
| 13:56 |
|
trygvis |
c+j with data demo instace |
| 13:56 |
|
trygvis |
instance |
| 14:05 |
|
michaelis |
pdurbin: Thank you. I found a simple tutorial on how to create a RESTful service on http://blog.miguelgrinberg.com/post/designing-a-restful-api-with-python-and-flask |
| 14:06 |
|
pdurbin |
michaelis: is there a demo instance to play with? |
| 14:13 |
|
michaelis |
pdurbin: I have no idea. |
| 14:13 |
|
pdurbin |
bummer |
| 14:15 |
|
michaelis |
pdurbin: Bummer. |
| 14:16 |
|
pdurbin |
whelp, if anyone spots one in the wild, please let us know |
| 14:17 |
|
pdurbin |
in other news: http://www.bostonglobe.com/lifestyle/2015/01/27/boston-yeti-loose-during-blizzard/acLFCAvV7aYj4sD2FsB8cO/story.html |
| 14:46 |
|
|
pgicxplzs joined #rest |
| 14:46 |
|
|
azer_ joined #rest |
| 15:08 |
|
bigbluehat |
anyone know if it's possible to construct an URI template for this URL? |
| 15:08 |
|
bigbluehat |
https://hypothes.is/stream?q=user:bigbluehat%20tag:history |
| 15:08 |
|
bigbluehat |
where everything inside ?q= is optional, but must either be a plain old string |
| 15:08 |
|
bigbluehat |
or have prefixes of user: tag: etc, |
| 15:09 |
|
bigbluehat |
I'm also wanting to be able to express that in an Open Search document http://www.opensearch.org/Specifications/OpenSearch/1.1#The_.22Url.22_element |
| 15:09 |
|
bigbluehat |
...but it seems out of scope for both of these specs |
| 15:22 |
|
|
dEPy joined #rest |
| 15:31 |
|
|
ruibritopt joined #rest |
| 15:32 |
|
|
fumanchu joined #rest |
| 15:32 |
|
|
tr3online joined #rest |
| 15:33 |
|
|
tr3online joined #rest |
| 15:33 |
|
|
tr3online joined #rest |
| 15:35 |
|
|
tr3online joined #rest |
| 16:00 |
|
|
Andre-B joined #rest |
| 17:11 |
|
|
jaawerth joined #rest |
| 17:13 |
|
jaawerth |
Hi folks. I'm working on a sort of gateway server, and I'm trying to build a RESTful API that abstracts a horrifically insane API protocol on the true backend service. The gateway does business logic but also effectively proxies and simplifies some calls to the backend |
| 17:14 |
|
jaawerth |
it's a document management system, so one example: when you make a call for a "node" (a document or a folder), the default behavior for a folder is to reply with children + metadata, for a file it will give you the actual content stream |
| 17:15 |
|
jaawerth |
but you can specify a selector via query param. "object" will give you just the metadata for the object in question (file OR folder), 'descendants' will give all descendants of a folder + metadata, etc |
| 17:15 |
|
jaawerth |
ALSO you can select an item by either objectID or by path |
| 17:16 |
|
jaawerth |
I'm thinking the RESTful representation to have /api/path/path/to/object and /api/node/:objectID/ , and then for the selectors simply append it at the end of the path params. Thoughts? |
| 17:17 |
|
jaawerth |
so, /api/node/ijaiwjiege/object would simply grab the object metadata, /api/path/path/to/object/descendants would grab the descendants, etc |
| 17:18 |
|
jaawerth |
does that sound about right? |
| 17:23 |
|
jaawerth |
or would it be better to have /api/:selector/id/:objectId, /api/:selector/path/path/to/object ? |
| 17:29 |
|
fumanchu |
explain :selector more |
| 17:29 |
|
|
azer_ joined #rest |
| 17:30 |
|
jaawerth |
Well, the protocol in question is CMIS, which lets you specify a "cmisselector" which is not quite the same as an SQL selector (it uses SQL syntax for queries, though) |
| 17:30 |
|
fumanchu |
so the selector is a param or set of params that filters what you get back |
| 17:30 |
|
jaawerth |
it's a single param that dictates what you get back - it isn't necessarily a filter |
| 17:31 |
|
jaawerth |
it can be further modified by other params to choose what is and isn't included in the response |
| 17:31 |
|
fumanchu |
so "object" is one valid selector, and "descendants" is another? |
| 17:31 |
|
fumanchu |
or is that a separate category |
| 17:31 |
|
jaawerth |
yeah. another is "children" which is the default for folders (and also only works for folders) |
| 17:31 |
|
fumanchu |
ok |
| 17:32 |
|
jaawerth |
"children" is the same as "descendants" but only goes one level |
| 17:33 |
|
jaawerth |
another selector would be "acl" which will give you just ACL information (but there's also an "includeACL" param that will add that info to other requests - it's a mess) |
| 17:33 |
|
fumanchu |
the only recommendation I have is that you make /api/path/path/to/object redirect to /api/node/:objectID/, rather than duplicate the returned representation. Then you can have the node move around but still retain its internal state more easily. |
| 17:34 |
|
fumanchu |
meaning: fewer lost updates if two people try to edit it and move it at the same time, for example |
| 17:34 |
|
jaawerth |
hm... so the path would only return the object ID, and then redirect to the objectID request with that information filled in? |
| 17:34 |
|
jaawerth |
because if someone uses the path to make the request, they may not have the objectID |
| 17:36 |
|
fumanchu |
a GET on the path would return a Location header with the url of the node resource, against which you would then make your "real" request |
| 17:36 |
|
jaawerth |
ahh |
| 17:36 |
|
jaawerth |
that makes sense |
| 17:36 |
|
jaawerth |
thanks |
| 17:36 |
|
fumanchu |
if your "real" request is a GET, then you can just follow the link automatically |
| 17:36 |
|
jaawerth |
what are your thoughts on putting the selectojr at the end vs the beginning? |
| 17:37 |
|
jaawerth |
or I could leave it as a query param and break from REST (which I'll probably have to do with some of those others) |
| 17:37 |
|
fumanchu |
a query param is not anti-REST |
| 17:37 |
|
fumanchu |
just keep in mind that query params are part of the URI, and different params identify different resources |
| 17:37 |
|
jaawerth |
hmm good call |
| 17:38 |
|
fumanchu |
I would put the selector at the end |
| 17:38 |
|
jaawerth |
that feels right, yeah. |
| 17:39 |
|
jaawerth |
now, the selector only applies for a GET. When making changes, there's an "action" param instead |
| 17:40 |
|
fumanchu |
it's not a tenet of REST, but it is a feature of HTTP: HTTP URI's are hierarchical in nature. So /api should feel like "all my data", /api/nodes/ should represent "all my nodes", /api/nodes/X/ should represent "node X", and /api/nodes/X/descendants should represent that part of that node's complete state |
| 17:40 |
|
fumanchu |
keep drilling down to smaller and smaller chunks of the total state |
| 17:40 |
|
jaawerth |
hmm thanks, that's helpful |
| 17:41 |
|
jaawerth |
which means it would be kosher to follow a similar appraoch for actions: POST/PUT /node/objectID for default action, /node/objectID/action/specifiedAction |
| 17:43 |
|
fumanchu |
yes, POST/PUT /node/objectID, but in general you don't need separate URL's for separate actions. Instead, pass the action instructions in the POST to node/objectID. |
| 17:43 |
|
fumanchu |
either your media type already has a way to express that, or you document the various kinds of actions and params in what you GET at node/objectID |
| 17:43 |
|
jaawerth |
d'oh, right |
| 17:44 |
|
jaawerth |
yeah, and my primary media type is application/json so that will be easy |
| 17:44 |
|
fumanchu |
you can make more URL's if you're addressing a subset of the total node state |
| 17:46 |
|
fumanchu |
(and if you want a JSON-based media-type that strongly encourages you to make these decisions correctly, try my https://bitbucket.org/fumanchu/shoji/src/tip/spec.txt?at=default <wink>) |
| 17:46 |
|
jaawerth |
hm... thanks. taking me back through the fundamentals has cleared my vision a lot. I had a billion params and selectors flying around me |
| 17:46 |
|
fumanchu |
yeah, there's a lot of complexity to wade through :) |
| 17:47 |
|
jaawerth |
CMIS is a really crazy protocol, probably because it was 1) designed by committee and 2) is an attempt to make a browser-friendly respresentation of a SOAP and ATOM API |
| 17:48 |
|
fumanchu |
I don't envy you that :) good luck |
| 17:48 |
|
jaawerth |
haha, thanks. And I'm definitely going to use this spec as a reference (a sanity check, if nothing else) |
| 19:34 |
|
|
begriffs joined #rest |
| 20:02 |
|
|
tr3online joined #rest |
| 20:16 |
|
|
shrink0r joined #rest |
| 20:18 |
|
|
tr3online joined #rest |
| 21:02 |
|
|
azer_ joined #rest |
| 22:06 |
|
|
shrink0r_ joined #rest |
| 22:23 |
|
|
warehouse13 joined #rest |
| 22:44 |
|
|
fumanchu joined #rest |
| 23:16 |
|
|
Left_Turn joined #rest |
| 23:17 |
|
|
azer_ joined #rest |
| 23:28 |
|
|
warehouse13 joined #rest |
| 23:39 |
|
|
fumanchu_ joined #rest |
