| Time |
S |
Nick |
Message |
| 00:08 |
|
|
SupaHam joined #rest |
| 00:53 |
|
|
wsiqueir joined #rest |
| 00:57 |
|
ModusPwnens |
How would one handle representing a resource that is computed/generated in response to a request but is never stored? |
| 01:16 |
|
sfisque |
does it matter what/how the data is derived? from a client standpoint it shouldnt matter if the data is a join, atomic serialization, stored in nosql, or coming out of a massive calculation |
| 01:20 |
|
pdurbin |
sfisque: let's build an REST API for /dev/random ;) |
| 01:20 |
|
sfisque |
i think it already exists :P |
| 01:21 |
|
sfisque |
https://www.random.org/ |
| 01:21 |
|
pdurbin |
I love https://randomuser.me |
| 01:21 |
|
|
fuzzyhorns joined #rest |
| 02:56 |
|
|
baweaver joined #rest |
| 03:45 |
|
|
ralphschindler joined #rest |
| 04:32 |
|
|
baweaver joined #rest |
| 04:50 |
|
|
fuzzyhorns joined #rest |
| 05:07 |
|
|
daxim_ joined #rest |
| 05:41 |
|
|
_ollie joined #rest |
| 06:55 |
|
|
baweaver joined #rest |
| 07:02 |
|
|
rosstuck joined #rest |
| 07:53 |
|
|
graste joined #rest |
| 08:41 |
|
|
fumanchu joined #rest |
| 08:57 |
|
|
fumanchu joined #rest |
| 09:27 |
|
|
quimrstorres joined #rest |
| 09:35 |
|
|
quimrstorres joined #rest |
| 09:47 |
|
|
quimrstorres joined #rest |
| 09:48 |
|
|
azer_ joined #rest |
| 11:16 |
|
|
darkangel joined #rest |
| 12:05 |
|
pokEarl |
Hello friends, a question about url building. Is it reasonable to specify resources further down in the path say like v1/item/onsale or v1/item/outofstock or is there better way I should be doing this |
| 12:09 |
|
|
quimrstorres joined #rest |
| 12:14 |
|
asdf` |
pokEarl, 'list of items on sale' can be a resource of its own, sure; ultimately there's little difference between item/onsale or item?onsale or item?sale=true etc, choose whichever fits your web framework; REST/HATEOAS however says that this url should be discovered by the client (so your /item resource can have a link to /item/onsale), not hardcoded in it |
| 12:20 |
|
|
eschmidbauer joined #rest |
| 12:47 |
|
|
darkangel left #rest |
| 13:17 |
|
|
eschmidbauer left #rest |
| 13:31 |
|
|
ralphschindler joined #rest |
| 13:35 |
|
|
quimrstorres joined #rest |
| 14:13 |
|
|
quimrstorres joined #rest |
| 14:33 |
|
|
wsiqueir joined #rest |
| 14:47 |
|
|
quimrstorres joined #rest |
| 14:55 |
|
|
quimrstorres joined #rest |
| 15:02 |
|
|
ChrisAnn_ joined #rest |
| 15:06 |
|
|
impl_ joined #rest |
| 15:10 |
|
|
FreezingDroid_ joined #rest |
| 15:19 |
|
|
DrCode joined #rest |
| 15:41 |
|
|
ralphschindler joined #rest |
| 16:33 |
|
|
mamund joined #rest |
| 17:06 |
|
|
quimrstorres joined #rest |
| 17:07 |
|
|
quimrsto_ joined #rest |
| 17:37 |
|
|
quimrstorres joined #rest |
| 17:52 |
|
|
baweaver joined #rest |
| 18:01 |
|
|
quimrstorres joined #rest |
| 18:04 |
|
|
yuciyuar joined #rest |
| 18:12 |
|
|
jgornick joined #rest |
| 18:15 |
|
|
dkm joined #rest |
| 18:17 |
|
|
quimrstorres joined #rest |
| 18:22 |
|
|
quimrstorres joined #rest |
| 19:11 |
|
|
rmwdeveloper joined #rest |
| 19:40 |
|
pokEarl |
an api using itself is not a great idea right? |
| 19:40 |
|
fumanchu |
it can be |
| 19:40 |
|
fumanchu |
especially if you want it to handle resources distributed across multiple domains |
| 19:42 |
|
fumanchu |
but for most simple services, it's just needless overhead to go all the way to the network card and back when you don't have to |
| 19:55 |
|
pokEarl |
hmmm decisions decisions |
| 19:55 |
|
pokEarl |
coupled with me not really knowing what I am doing ^___^ |
| 20:00 |
|
pokEarl |
If it is just logic between different mongo collections on the same database though, then not using my own api but instead doing seperate calls will lead to better performance? |
| 20:00 |
|
fumanchu |
almost certainly |
| 20:01 |
|
fumanchu |
using your own HTTP API at that point just does the same work plus extra work to wrap the call in an HTTP request/response |
| 20:02 |
|
fumanchu |
in even a well-optimized system, that can add a few milliseconds per call |
| 20:03 |
|
fumanchu |
and often increases the opportunity for unrelated errors |
| 20:05 |
|
sfisque |
pokEarl it makes sense if the link is "discovered" and the services are clustered |
| 20:06 |
|
pokEarl |
I need to turn of that textual sound it always scares the shit out of me :( |
| 20:08 |
|
pokEarl |
hm but ok don't think that is applicable then |
| 20:10 |
|
sfisque |
additionally, IF you foresee the resource being migrated out to a different service, then it could be "an intermediary step" where it makes an external call, but the call is routed back to itself, until such time as the external service comes online, then the the code stays the same, other than feeding it a different url |
| 20:12 |
|
sfisque |
some could argue that might be over-engineering, but in a world where sprints can be 1-2 weeks in length, taking an intermediate step could be useful |
| 20:22 |
|
|
baweaver joined #rest |
| 21:29 |
|
pokEarl |
Hmm, so sort of not sure how to best organize my project (Java), and most examples i find online are just simple Hello world tutorials or whatever. Anyone have any suggestions of where I might find a well organized somewhat larger RestAPI done in Java? |
| 21:34 |
|
pdurbin |
pokEarl: do you want real REST or RPC over HTTP? :) |
| 21:37 |
|
pdurbin |
either way you're welcome to poke around at https://github.com/IQSS/dataverse/tree/master/src/main/java/edu/harvard/iq/dataverse/api |
| 21:38 |
|
pokEarl |
Hmm.. Restlike? :( I am not sure hateoas is the right way to go for me but most of the rest concepts seem to be sound |
| 21:40 |
|
whartung |
well what's to organize, what are you organizing? are you using a toolkit? what else are you using. all sorts of things can affect layout. |
| 21:47 |
|
whartung |
I tend to organize my projects: frontend <-> shared lib with interfaces <-> backend |
| 21:49 |
|
pdurbin |
whartung: so, 3 maven projects (or whatever)? |
| 21:49 |
|
whartung |
yea |
| 21:50 |
|
pdurbin |
doesn't feel like overkill? |
| 21:50 |
|
whartung |
not to me |
| 21:51 |
|
pdurbin |
ok |
| 21:51 |
|
pdurbin |
whartung: any examples that you've open sourced? |
| 21:51 |
|
pokEarl |
Hmm I can see that =p I am using Dropwizard and using the api to access a mongoDB |
| 21:53 |
|
whartung |
no, pdurbin - it's just what we do inside. |
| 21:54 |
|
whartung |
historically, they lined up with -war, -lib, -ebj pdurbin |
| 21:54 |
|
whartung |
-ejb |
| 21:54 |
|
pdurbin |
I guess the shared lib is what I'd want to see |
| 21:54 |
|
whartung |
so the ejb interfaces would be in the lib |
| 21:54 |
|
whartung |
war depends on the lib |
| 21:54 |
|
whartung |
ejb depends on the lib |
| 21:54 |
|
whartung |
war and ejb are separate from each other |
| 21:55 |
|
whartung |
gets fuzzier with the modern combined packaging (i.e. everything inthe war) |
| 21:55 |
|
|
baweaver joined #rest |
| 21:56 |
|
pdurbin |
we just build a monolith. a war |
| 21:57 |
|
whartung |
sure |
| 21:57 |
|
whartung |
now you're just talking package names |
| 21:58 |
|
pdurbin |
I guess |
| 21:59 |
|
|
fuzzyhorns joined #rest |
| 22:04 |
|
pdurbin |
pokEarl: any of this helping? :) |
| 22:07 |
|
pdurbin |
whartung: one git repo for all three projects? |
| 22:07 |
|
whartung |
yea |
| 22:07 |
|
whartung |
well |
| 22:07 |
|
whartung |
yea |
| 22:07 |
|
pdurbin |
makes sense |
| 22:12 |
|
|
fuzzyhorns joined #rest |
| 22:14 |
|
pokEarl |
Some of it I guess. but I think I just need to dive in and refactor myself to victory or something, sometimes just feels like the more I read the more confused I become |
| 22:15 |
|
whartung |
the internet is dangerou |
| 22:15 |
|
whartung |
just do stuff and don't worry about it |
| 22:16 |
|
pdurbin |
pokEarl: what is your API supposed to do again? |
| 22:21 |
|
pokEarl |
We have some various internal services (a web Dashboard written in js and some Java.. applications?) that access MongoDB (and SQL which I guess the api might expand to?) I am writing the api as a layer over the databases so that these things can access the database through http requests and get what they want back in Json. I think that makes sense? |
| 22:23 |
|
pdurbin |
yep. we do the same thing. APIs in Java as a layer over Postgres and Solr |
| 22:23 |
|
pdurbin |
pokEarl: I take it you're using JAX-RS. |
| 22:24 |
|
pokEarl |
Yeah, or well Jersey which I guess includes Jax-rs or something? |
| 22:25 |
|
pdurbin |
Jersey is the reference implementaion of the JAX-RS standard. |
| 22:28 |
|
|
azer_ joined #rest |
| 22:37 |
|
pokEarl |
Currently the way I am setting up my urls which is one of the things I am a bit not sure about is MongoCollectionName/WhatCollectionDocumentsYouWant/TheFieldsToReturn kind of. for example items/forsale/ids this seems sort of like the wrong way of doing it though but im not sure how i avoid the supposedly not good RPC way of doing it where you end up having tons of different methods like items/forsale items/instock items/forsaleinstock etc. Hmm. I guess I |
| 22:37 |
|
pokEarl |
should be using paramteres here but it would seem like it might be complicated to match all the different parameters or maybe not. |
| 22:38 |
|
whartung |
are you caching? |
| 22:38 |
|
pokEarl |
Well not yet, but I guess I will be? |
| 22:38 |
|
whartung |
I dunno, will you? |
| 22:40 |
|
pokEarl |
Would that alter how I want to build my urls? Because I guess MongoDB does caching so maybe I wouldn't need to |
| 22:41 |
|
whartung |
how many clients will use this service? |
| 22:41 |
|
whartung |
i.e. who will be writing code aginst this service |
| 22:42 |
|
whartung |
not how many sockets will it need to support |
| 22:42 |
|
pokEarl |
Not many people, we are a pretty tight knit team currently of 3 other coders than me, guess it will expand a bit soon but not by much |
| 22:43 |
|
whartung |
then go RPC and move on. |
| 22:51 |
|
pokEarl |
hmm maybe you are right, but I guess since I am not fully restful in the first place am I already doing RPC over http? By going RPC is what you mean that I should drop building around nonverbs/ the get/post/put etc and instead just have v1/getItem v1/updateItem etc? |
| 22:53 |
|
whartung |
basically, keep with http etc, but don't worry to much about it. Just do what seems to fit for your service. There are no constraints beyond the "WHAT THE HECK IS THIS!?!?" of your co-workers, and you can buy them beers if all else fails... |
| 22:59 |
|
pdurbin |
beers++ |
| 23:00 |
|
pdurbin |
I feel like we could improve our API a lot but people seem happen enough with it. |
| 23:01 |
|
whartung |
si |
| 23:02 |
|
pdurbin |
happy* |
| 23:30 |
|
|
azer_ joined #rest |
| 23:39 |
|
pokEarl |
I had to leave the office just as I responded whartung so I was basically walking home thinking oh well guess I must start completeply over and HTTP/JSON is probably not good enough either and maybe i better switch away from java and fml 8< |
| 23:39 |
|
whartung |
fml? |
| 23:40 |
|
pokEarl |
fuck my life |
| 23:41 |
|
whartung |
why switch away from java? |
| 23:42 |
|
pokEarl |
No I am not going to and was not really thinking that I had to, was just overimagining the need for dramatic change in what I have already learned/done |
| 23:43 |
|
whartung |
why's that what needs to "dramatically" change? |
| 23:44 |
|
pokEarl |
It doesn't |
| 23:44 |
|
whartung |
oic |
| 23:44 |
|
whartung |
so waht are you doing now then? |
| 23:45 |
|
pokEarl |
keeping with http etc but not worrying too much about it and just doing what seems to fit for my service =p |
| 23:45 |
|
whartung |
ah good |
