| Time |
S |
Nick |
Message |
| 00:24 |
|
|
co-arbelos joined #rest |
| 00:36 |
|
|
shrink0r_ joined #rest |
| 01:48 |
|
|
shrink0r joined #rest |
| 04:37 |
|
|
co-arbelos joined #rest |
| 04:44 |
|
|
SarahAngel joined #rest |
| 04:46 |
|
SarahAngel |
I'm building out a REST API that will have a public API and private API, the web service will be split up into 2 applications, the backend API server and the front-end app, the front-end app will need various endpoints that are private to just that client_id and not available to others |
| 04:46 |
|
SarahAngel |
Would scopes be a good solution for this? Define scope that I can give to that one single client_id to give it access to those endpoints? |
| 04:46 |
|
SarahAngel |
while the public API clients never be able to get that scope |
| 04:47 |
|
SarahAngel |
for example the registration of new applications for developers (to access our public API) has to go over that same API |
| 04:47 |
|
SarahAngel |
but I dont want to expose those endpoints to the general public |
| 05:35 |
|
|
vanHoesel joined #rest |
| 05:40 |
|
|
ewalti joined #rest |
| 06:08 |
|
|
_ollie joined #rest |
| 06:15 |
|
|
wsiqueir joined #rest |
| 06:20 |
|
|
_ollie joined #rest |
| 07:32 |
|
|
Andre-B joined #rest |
| 07:52 |
|
|
shrink0r joined #rest |
| 08:02 |
|
|
graste joined #rest |
| 08:49 |
|
|
quimrstorres joined #rest |
| 08:53 |
|
|
Left_Turn joined #rest |
| 08:56 |
|
|
quimrstorres joined #rest |
| 09:30 |
|
|
arbelos joined #rest |
| 09:46 |
|
|
mezod joined #rest |
| 10:04 |
|
|
quimrstorres joined #rest |
| 10:09 |
|
pdurbin |
oh. she's gone |
| 10:10 |
|
pdurbin |
we put all of our developer/admin endpoints under "/admin" - http://guides.dataverse.org/en/latest/api/native-api.html#admin |
| 10:10 |
|
|
quimrsto_ joined #rest |
| 10:11 |
|
pdurbin |
and we have various ways to block endpoints: https://github.com/IQSS/dataverse/blob/master/scripts/api/post-install-api-block.sh |
| 11:19 |
|
|
CentaurWarchief joined #rest |
| 11:24 |
|
|
shrink0r joined #rest |
| 11:36 |
|
|
dEPy joined #rest |
| 11:38 |
|
|
shrink0r joined #rest |
| 12:16 |
|
|
scflode joined #rest |
| 12:55 |
|
|
interop_madness joined #rest |
| 13:12 |
|
|
quimrstorres joined #rest |
| 13:13 |
|
|
pezra joined #rest |
| 13:54 |
|
|
co-arbelos joined #rest |
| 14:22 |
|
|
saml joined #rest |
| 14:54 |
|
fumanchu_ |
pdurbin: we run admin endpoints on a different port in the same process |
| 14:55 |
|
fumanchu_ |
a little easier to maintain lockdown |
| 14:56 |
|
pdurbin |
fumanchu_: here's how we do it: https://github.com/IQSS/dataverse/blob/master/src/main/java/edu/harvard/iq/dataverse/api/ApiBlockingFilter.java |
| 14:59 |
|
|
ewalti joined #rest |
| 15:03 |
|
fumanchu_ |
looks like a config setting away from a hole ;) |
| 15:08 |
|
|
co-arbelos joined #rest |
| 15:12 |
|
pdurbin |
:) |
| 15:16 |
|
|
fumanchu joined #rest |
| 15:17 |
|
arbelos |
Has anyone here used apiary.io? |
| 15:30 |
|
arbelos |
or API blueprint? |
| 15:36 |
|
pdurbin |
I've heard of the former, at least. |
| 15:39 |
|
arbelos |
it seems apiary is, sort of, building on top of API blueprint |
| 15:39 |
|
arbelos |
which wasn't clear to me at first |
| 15:40 |
|
arbelos |
I was a bit confused about the lack of documentation |
| 15:41 |
|
arbelos |
but I think I found what I was looking for now |
| 15:43 |
|
arbelos |
so, API Blueprint is a format, or description language around which apiary.io (a service) is built |
| 15:43 |
|
arbelos |
that is my understanding at least |
| 16:06 |
|
|
co-arbelos joined #rest |
| 16:36 |
|
|
arbelos joined #rest |
| 17:10 |
|
|
tieTYT2 joined #rest |
| 17:18 |
|
|
ewalti joined #rest |
| 17:52 |
|
|
co-arbelos joined #rest |
| 18:23 |
|
arbelos |
So, referenced objects in a response should be links? It is not nice to expand objects or is it at my discretion? |
| 18:25 |
|
asdf` |
arbelos, sure, links are how you reference other things; by 'expand' you mean embedding the other thing in the representation? you can do that but keep caching in mind: if you include the other thing, now your response is less cacheable, because it'd need to be invalidated when either the main or the embedded thing changes |
| 18:26 |
|
fumanchu |
beat me to it :) |
| 18:26 |
|
arbelos |
ok i see, that is a good point |
| 18:26 |
|
asdf` |
arbelos, note eg. how HAL does this, btw: http://stateless.co/hal_specification.html (the '_embedded' thing) |
| 18:26 |
|
arbelos |
but doesn't lots of links introduce quite some overhead |
| 18:27 |
|
arbelos |
or i guess that is what the caching is there for |
| 18:27 |
|
asdf` |
yeah pretty much |
| 18:28 |
|
fumanchu |
yes and no. managing the efficiency of large representations versus lots of requests is what's really at your discretion |
| 18:28 |
|
asdf` |
(and when it really starts to become a problem, then you can start embedding) |
| 18:29 |
|
arbelos |
ok, interesting |
| 18:29 |
|
fumanchu |
the more caching you do, the more you can do few, larger responses |
| 18:38 |
|
|
SarahAngel joined #rest |
| 18:41 |
|
|
wsiqueir joined #rest |
| 19:46 |
|
|
tieTYT2 joined #rest |
| 19:51 |
|
|
ewalti joined #rest |
| 20:03 |
|
|
ralphschindler joined #rest |
| 20:22 |
|
|
ralphschindler joined #rest |
| 20:31 |
|
|
tieTYT2 joined #rest |
| 21:51 |
|
|
happyface joined #rest |
| 21:56 |
|
|
ralphschindler joined #rest |
| 23:42 |
|
|
ralphschindler joined #rest |
