Time  Nick       Message
18:29 fumanchu   the more caching you do, the more you can do few, larger responses
18:29 arbelos    ok, interesting
18:28 asdf`      (and when it really starts to become a problem, then you can start embedding)
18:28 fumanchu   yes and no. managing the efficiency of large representations versus lots of requests is what's really at your discretion
18:27 asdf`      yeah pretty much
18:27 arbelos    or i guess that is what the caching is there for
18:26 arbelos    but doesn't lots of links introduce quite some overhead
18:26 asdf`      arbelos, note eg. how HAL does this, btw: http://stateless.co/hal_specification.html (the '_embedded' thing)
18:26 arbelos    ok i see, that is a good point
18:26 fumanchu   beat me to it :)
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:23 arbelos    So, referenced objects in a response should be links? It is not nice to expand objects or is it at my discretion?
15:43 arbelos    that is my understanding at least
15:43 arbelos    so, API Blueprint is a format, or description language around which apiary.io (a service) is built
15:41 arbelos    but I think I found what I was looking for now
15:40 arbelos    I was a bit confused about the lack of documentation
15:39 arbelos    which wasn't clear to me at first
15:39 arbelos    it seems apiary is, sort of, building on top of API blueprint
15:36 pdurbin    I've heard of the former, at least.
15:30 arbelos    or API blueprint?
15:17 arbelos    Has anyone here used apiary.io?
15:12 pdurbin    :)
15:03 fumanchu_  looks like a config setting away from a hole ;)
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:55 fumanchu_  a little easier to maintain lockdown
14:54 fumanchu_  pdurbin: we run admin endpoints on a different port in the same process
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
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:09 pdurbin    oh. she's gone
04:47 SarahAngel but I dont want to expose those endpoints to the general public
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:46 SarahAngel while the public API clients never be able to get that scope
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 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