| Time |
S |
Nick |
Message |
| 00:57 |
|
|
tr3online joined #rest |
| 01:38 |
|
|
StatelessCat joined #rest |
| 04:08 |
|
|
blahdeblah joined #rest |
| 04:11 |
|
|
blahdeblah joined #rest |
| 04:49 |
|
|
blahdeblah joined #rest |
| 05:33 |
|
|
fsvehla joined #rest |
| 06:31 |
|
|
jackalista joined #rest |
| 06:54 |
|
|
mezod joined #rest |
| 07:03 |
|
|
shrink0r joined #rest |
| 07:26 |
|
|
fsvehla joined #rest |
| 08:05 |
|
|
graste joined #rest |
| 08:10 |
|
|
shrink0r joined #rest |
| 08:12 |
|
|
interop_madness joined #rest |
| 08:38 |
|
|
Left_Turn joined #rest |
| 08:56 |
|
|
quimrstorres joined #rest |
| 09:11 |
|
|
quimrstorres joined #rest |
| 10:32 |
|
trygvis |
yeah |
| 11:35 |
|
|
mezod joined #rest |
| 13:28 |
|
|
angular_mike joined #rest |
| 13:30 |
|
angular_mike |
for paginated resource item listing is it better to implement a `count` method, or include total number of items in the responses related to the resource? |
| 13:37 |
|
jackalista |
spring data jpa infra gives you current page number out of total number of pages and page size, I found that mostly sufficient |
| 13:38 |
|
angular_mike |
jackalista: oh? |
| 13:38 |
|
jackalista |
not sure if this is helpful, but what we did was to take the pagination exposed by spring data jpa and expose it via services |
| 13:38 |
|
jackalista |
mostly unchanged |
| 13:39 |
|
jackalista |
allowed us to set a page size and then page throught results, etc. works pretty nicely and easy impl |
| 13:40 |
|
jackalista |
I like that data access layer for reasons like that :) |
| 13:44 |
|
|
quimrstorres joined #rest |
| 13:47 |
|
angular_mike |
jackalista: sorry, what is spring data jpa? |
| 13:48 |
|
|
mgomezch joined #rest |
| 13:56 |
|
|
asta22 joined #rest |
| 14:07 |
|
|
jackalista joined #rest |
| 14:14 |
|
|
shrink0r joined #rest |
| 14:17 |
|
|
fission6 joined #rest |
| 14:17 |
|
fission6 |
Hello, i am faced with the following |
| 14:17 |
|
fission6 |
basicallt in a position where we have a bunch of current SOAP services, we have a new platform where we are building REST APIs, the tech team is making a case to use a translation service to translate SOAP to REST. The issue I have is that its not nessarily a one to one mapping in API endpoints available and the two systems are fundementally different. |
| 14:17 |
|
fission6 |
I am trying ot understand the ideal use case to use a SOAP->REST translation service and see if it actually lines up with our situation |
| 14:21 |
|
saml |
do you want to replace SOAP with REST? |
| 14:21 |
|
saml |
or still keep SOAP for legacy clients.. etc |
| 14:22 |
|
fission6 |
so let me try to explain |
| 14:22 |
|
fission6 |
we have an old system which is SOAP based |
| 14:22 |
|
fission6 |
we have a new system we are building which offers a lot of functionality the old system did not |
| 14:22 |
|
saml |
let's call it v1 |
| 14:22 |
|
saml |
let's call the new v2 |
| 14:22 |
|
fission6 |
well they aren;t versions |
| 14:22 |
|
saml |
doesn't matter. just two different apis |
| 14:22 |
|
fission6 |
they are two seperate platforms that do things a bit different but focus on marketing |
| 14:23 |
|
fission6 |
ok |
| 14:23 |
|
saml |
are you asking weather v2 can use v1 or not? |
| 14:23 |
|
fission6 |
so the old platform has many custome applications built around it for clients which use api v1. |
| 14:23 |
|
fission6 |
we are building a new platform with many enhancements and a new UI to do a lot things previously in |
| 14:24 |
|
fission6 |
app form on the old system. the new platform will have a RESTful API exposed as well for certain functionality, some overlaps with v1 some does not. |
| 14:25 |
|
fission6 |
When we go to miugrate the clients to the new system, we are getting a lot of pushback around why do we need to migrate the applications vs translate their calls to the new system through a compatapibily layer / soap->rest gateway |
| 14:25 |
|
fission6 |
to me thats a very idialogogy assumption that it would be that seamless |
| 14:25 |
|
saml |
so you want to keep v1. but v1 uses v2 |
| 14:25 |
|
fission6 |
some assumptions include, that there is an api call which makes in both versions for starters |
| 14:26 |
|
saml |
you need to rewrite v1 in addition to writing v2 |
| 14:27 |
|
saml |
i'd just finish v2. make it stable. then worry about client migration. client migration can be done in the form of rewriting v1. or update each client to use v2. |
| 14:27 |
|
fission6 |
nope, v1 stays v2 is being built, lots of applications using v1 which is SOAP, we need to migrate to v2 —remeber v2 is hitting a while new product |
| 14:27 |
|
saml |
so, finish v2. migrate clients to v2. kill v1. |
| 14:27 |
|
fission6 |
saml — well thats my main point to is hey, a compatability layer *Could* work but we need to focus on building v2 first, can’t map shit without something to map too |
| 14:28 |
|
saml |
usually, api design goes hand in hand with client development |
| 14:28 |
|
fission6 |
saml - thats the plan but the tech side is scared that client swill not want to make code changes and that it could be easier to introduce a gateway to map old API calls to the new ones |
| 14:29 |
|
saml |
if you only have control on v1 and v2, and not clients.. you don't have many choices |
| 14:29 |
|
saml |
everything works fine currently right? |
| 14:30 |
|
saml |
why not just keep v1 running as is? and release v2... and let clients change to v2 in a year or two.. deprecate v1. |
| 14:30 |
|
saml |
if you want to add new feature to v1.. you need to work more |
| 14:30 |
|
saml |
just let your boss know all new features will be in v2 only. v1 will be frozen as is and depreacated. |
| 14:31 |
|
fission6 |
i think y ou are thining of different api vcersions |
| 14:31 |
|
fission6 |
its two different platforms |
| 14:32 |
|
|
apiguy joined #rest |
| 14:34 |
|
|
apiguy joined #rest |
| 14:37 |
|
saml |
yah i'd just delete node.js platform |
| 14:53 |
|
|
foist joined #rest |
| 14:54 |
|
foist |
I have a hard time deciding whether to represent something as a nested resource or as a top-level resource. Is there some guideline for this? |
| 14:55 |
|
foist |
For instance, I have workers, logs, and locations. Workers create logs at locations. Should it be /workers/1/locations/23/logs/? Or /locations/23/logs/, or just /logs/? |
| 14:59 |
|
|
fission6 joined #rest |
| 14:59 |
|
fission6 |
sorry saml you there |
| 14:59 |
|
fission6 |
computer shut down |
| 14:59 |
|
fission6 |
curious if you had more thoughts |
| 14:59 |
|
saml |
not much thought |
| 15:00 |
|
saml |
foist, i'd think representation of /logs/1 will contain links to worker and location. |
| 15:01 |
|
foist |
saml: yes, it certainly would. |
| 15:01 |
|
saml |
so those information can be in representation. doesn't have to be in url |
| 15:02 |
|
foist |
I do need to be able to retrieve all locations, irrespective of whether the location has any logs. |
| 15:02 |
|
saml |
/logs |
| 15:03 |
|
foist |
But sometimes a location may exist with out a log. |
| 15:03 |
|
foist |
/locations, no? |
| 15:03 |
|
saml |
so you have three collections /logs, /locations, /workers |
| 15:04 |
|
saml |
you can filter logs by location or workers.. and vice versa |
| 15:04 |
|
saml |
/logs?location=berlin&worker=foist |
| 15:06 |
|
foist |
or /locations?worker=foist |
| 15:06 |
|
sfisque |
wouldnt you treat them as both top level AND nested. conceivably you could have an endpoint that represented logs "in the whole", vs "logs contextually belonging to a parent" |
| 15:06 |
|
foist |
You’re saying represent all three collections as top level end-points along with filtering in each one? |
| 15:06 |
|
sfisque |
that would seem to make the most sense to me |
| 15:07 |
|
sfisque |
that's the beauty of the hypertext world, context :-) |
| 15:08 |
|
foist |
sfisque: so do you mean both /logs along with /workers/1/logs? |
| 15:09 |
|
sfisque |
blah/logs?params=bleh == logs in teh whole with some culling aspects vs /blah/workers/blargh/logs?params=blooey == logs belonging to blargh with some culling aspects |
| 15:09 |
|
sfisque |
yes |
| 15:09 |
|
foist |
In that case would /workers/1/locations/5/logs also seem appropriate? |
| 15:09 |
|
sfisque |
yes |
| 15:11 |
|
sfisque |
your context dictates the result not the type. don't mix address (uri) with type. you can store the same "type" at different locations. what the locations dictate is a view into your system that can be acted on (put, del, post, etc.) |
| 15:11 |
|
foist |
sorry, what does “type” mean in this context? |
| 15:12 |
|
sfisque |
in your example, workers, logs, and locations are "types" |
| 15:12 |
|
foist |
but /workers, /log, /locations are the URIs |
| 15:12 |
|
sfisque |
so you don't have to think of them existing at a single uri. they can exists at many uri's depending on context |
| 15:12 |
|
sfisque |
they are, but they are "context" |
| 15:13 |
|
foist |
They are both types and context? |
| 15:13 |
|
sfisque |
yes. that is the nature of any hierarchical system |
| 15:13 |
|
sfisque |
similar to ldap or any directory service |
| 15:13 |
|
foist |
They are types when accessed as the bare URI, and are context when provided as a query param? |
| 15:14 |
|
sfisque |
uri component |
| 15:14 |
|
sfisque |
query params are culling mechanisms |
| 15:14 |
|
foist |
What is a culling mechanism? |
| 15:14 |
|
foist |
Filtering, you mean? |
| 15:14 |
|
sfisque |
yes |
| 15:15 |
|
foist |
Worker 2 is context for the location: /locations/1/workers/2? |
| 15:15 |
|
sfisque |
i dislike the world "filtering" because it gets used in a lot of different contexts and means different things |
| 15:15 |
|
sfisque |
locations 1 is the context for workers 2 |
| 15:16 |
|
foist |
Can you elaborate on "don't mix address (uri) with type." |
| 15:19 |
|
sfisque |
bah, i typed up a bunch of stuff and adium barfed.. i'll try to retype it |
| 15:19 |
|
foist |
Appreciate the help :) |
| 15:21 |
|
sfisque |
basically a uri indicates a view into your system, not the "type" of the return. essentially, you can have many endpoints that return the same type, so the uri is not a type, but a view that returns a particular type. this may appear trivial, but failing to keep that in mind can become a trap. basically just because i can obtain a worker at uri x/y/z/worker does not mean i cannot obtain a worker at a/b/c/d/worker. both e |
| 15:23 |
|
sfisque |
likewise, those two uri's could return different types even though they are both "worker" uri's. one could return personal information (like an HR system endpoint) and the other one could return timecard info (payroll system endpoint) |
| 15:25 |
|
sfisque |
that's a kind of obtuse example, but i hope you get what i'm trying to convey |
| 15:26 |
|
foist |
Yes, I understand. |
| 15:27 |
|
foist |
Thanks, sfisque. I’ll try to run with that. |
| 15:27 |
|
sfisque |
npnp. be well |
| 15:32 |
|
foist |
sfisque: what if I want a POST access point at /workers/1/locations, but do not want to expose /workers for a GET? |
| 15:38 |
|
fumanchu |
that's no problem. it's totally up to the server to return what it wants (even a 404 Not Found or 405 Method Not Allowed) for any URL in its domain |
| 15:38 |
|
foist |
Is that wrong or bad in some way? |
| 15:38 |
|
foist |
fumanchu: great. Thanks. |
| 15:39 |
|
fumanchu |
the thing to think about is how to communicate to the client that a POST to workers/1/locations is desirable and when/why |
| 15:39 |
|
foist |
Is there a book out there that covers REST fundamentals in great depth? Or is Roy Fielding’s paper pretty much the definitive resource? |
| 15:40 |
|
fumanchu |
Fielding's paper is why. There are lots of books on how. |
| 15:40 |
|
foist |
Should one start with the why? |
| 15:41 |
|
fumanchu |
only if nobody above you knows why ;) |
| 15:41 |
|
foist |
I’m pretty autonomous in this effort. |
| 15:42 |
|
foist |
What’s a good book on the why? |
| 15:42 |
|
fumanchu |
then I'd start with the how and that will give you some context to understand the why |
| 15:42 |
|
foist |
s/why/how |
| 15:42 |
|
fumanchu |
Richardson/Ruby is often recommended |
| 15:43 |
|
fumanchu |
ah, I see mamund contributed to its successor: http://www.restfulwebapis.org/ |
| 15:45 |
|
foist |
Great, will try to fit that into my schedule. |
| 15:46 |
|
fumanchu |
oo, and the former is now a free download: http://www.restfulwebapis.org/rws.html |
| 15:47 |
|
foist |
Have things really changed so much that there’s a whole new book required to describe modern techniques and knowledge? |
| 15:47 |
|
foist |
REST does not seem like something that is subject to change. |
| 15:51 |
|
fission6 |
anyone here ever work with an API gateway |
| 16:06 |
|
fumanchu |
foist: REST itself is an architectural style and doesn't really change. But the "materials" do and people continue to learn things about how to implement REST for different needs. |
| 16:06 |
|
fumanchu |
and frankly how to communicate it better |
| 16:46 |
|
whartung |
I think I have that book at home... |
| 17:25 |
|
|
quimrstorres joined #rest |
| 18:24 |
|
|
fission6 joined #rest |
| 18:28 |
|
sfisque |
question about json encoding. what does it mean if an endpoint returns a record with "$" as attribute name? |
| 18:30 |
|
sfisque |
e.g. if you hit this endpoint, you see a record that lis littered with "$" attribute names: http://whois.arin.net/rest/ip/75.75.75.75.json |
| 18:31 |
|
whartung |
$ is a valid attribute characeter, like _, right? |
| 18:31 |
|
whartung |
"doesn't mean anything" |
| 18:31 |
|
whartung |
apparently "@" is valid as well |
| 18:32 |
|
sfisque |
yes, but not sure if it means anything interesting, and how would that be mapped in say, java where "$" has special treatment (innerclass delimiter) |
| 18:32 |
|
whartung |
well, here is seems they're used for single valued properties |
| 18:32 |
|
whartung |
endAddrees, handle, name, description |
| 18:33 |
|
whartung |
all seem single valued. |
| 18:33 |
|
whartung |
why they chose to use a $ is a curious question |
| 18:33 |
|
sfisque |
right, i guess why bother doing that when they could just do attribute : value |
| 18:33 |
|
sfisque |
aye |
| 18:33 |
|
whartung |
right |
| 18:33 |
|
whartung |
oic |
| 18:33 |
|
whartung |
{"net":{"@xmlns":{ |
| 18:33 |
|
whartung |
this isn't json |
| 18:33 |
|
whartung |
it's XML converted to JSON :) |
| 18:33 |
|
sfisque |
AH |
| 18:34 |
|
whartung |
<version>123</version> == "version" : {"$":123} |
| 18:34 |
|
sfisque |
and since xml allows N many of the same tag |
| 18:34 |
|
sfisque |
right |
| 18:34 |
|
whartung |
no, because it allow content |
| 18:34 |
|
whartung |
it's a crummy xml to json converter |
| 18:34 |
|
sfisque |
oh so in this case $ constitutes "body" attribute |
| 18:34 |
|
whartung |
yes |
| 18:34 |
|
sfisque |
that makes sense |
| 18:34 |
|
sfisque |
thx |
| 18:34 |
|
sfisque |
:-) |
| 18:35 |
|
whartung |
have fun coaxing Jackson or GSON to serilaize this stuff lol |
| 18:35 |
|
sfisque |
second pair of eyes wins! |
| 18:35 |
|
whartung |
I mean, they even converted the name spaces lol |
| 18:35 |
|
sfisque |
quick question. i know java 8 bakes json api into the jdk, does it also bundle an impl or is it just the api? thinking of switching project to 8 |
| 18:35 |
|
whartung |
the @name are attributes |
| 18:36 |
|
sfisque |
aye that's xpath |
| 18:36 |
|
sfisque |
@attr_name |
| 18:36 |
|
whartung |
oh, I think it has an operational implementation |
| 18:36 |
|
whartung |
JDK isn't really known for just bundleing interfaces |
| 18:36 |
|
whartung |
but I've not used it |
| 18:36 |
|
sfisque |
au contraire |
| 18:36 |
|
sfisque |
<cough> jdbc </cough> |
| 18:37 |
|
whartung |
yes, but that's one of the very few. |
| 18:37 |
|
whartung |
JAX-WS, XML... |
| 18:37 |
|
sfisque |
aye |
| 18:37 |
|
whartung |
and the JDK bundles Derby :D |
| 18:38 |
|
sfisque |
eventually it did, yeah |
| 18:38 |
|
sfisque |
i forgot they subsumed derby |
| 18:39 |
|
sfisque |
i kick myself for never donating the directory server i wrote back in '99 as a reference impl for jndi |
| 18:39 |
|
sfisque |
live and learn |
| 18:40 |
|
whartung |
I've been writing an LDAP parser past week. |
| 18:41 |
|
sfisque |
for query strings or for the wire protocol? |
| 18:41 |
|
whartung |
wire protocol |
| 18:41 |
|
whartung |
BER yo! |
| 18:41 |
|
sfisque |
you know there are several BER libraries available, right? |
| 18:41 |
|
whartung |
BER != LDAP tho |
| 18:42 |
|
whartung |
with all the Application and CHOICEs |
| 18:42 |
|
whartung |
the basic decoding isnt difficult |
| 18:42 |
|
sfisque |
true, but no need to do parsing, just need to interpret the tokens generated from a ber library |
| 18:42 |
|
whartung |
<thing> <length> <stuff> |
| 18:43 |
|
sfisque |
any good ber lib will parse and hand you a tree and then you just need to descend and interpret |
| 18:43 |
|
whartung |
that's what parsing is -- interpeting tokens :) |
| 18:43 |
|
sfisque |
ok fair enough |
| 18:43 |
|
whartung |
they can't give me a reasonable DOM without LDAP context. |
| 18:44 |
|
whartung |
SEQEUNCE APPLICATION <BLOB> |
| 18:44 |
|
sfisque |
so i guess you're leveraging a lib to lex the stream? |
| 18:44 |
|
whartung |
"thanks" |
| 18:44 |
|
sfisque |
at the very least |
| 18:44 |
|
sfisque |
? |
| 18:44 |
|
whartung |
no, no need. I figured out how to read a length and decode the tag. |
| 18:45 |
|
* sfisque |
smacks whartung for reinventing the square wheel |
| 18:45 |
|
sfisque |
i think at&t has a job opening for you |
| 18:45 |
|
sfisque |
:P |
| 18:45 |
|
whartung |
Sun has a basic BER decoder, and it's not particularly useful. |
| 18:45 |
|
whartung |
BouncyCastle has a stream decoder, and it's not particularly useful. |
| 18:46 |
|
whartung |
the Sun one requires a BUFFER, not a stream, so I have to decode the stream myself anyway. |
| 18:46 |
|
whartung |
once I have that, I have the basic tokenizer ANYWAY |
| 18:47 |
|
whartung |
they don't read the sequences easily, I might gain a free octet string reader -- Ooh! there's time saved! |
| 18:47 |
|
sfisque |
aye. back in the day i looked at leveraging a library. i'll see if i can recover the reference (time to dig back 15 years) |
| 18:47 |
|
whartung |
most of the LDAP constructs are just seuqneces ibehind app tags and context tags |
| 18:47 |
|
whartung |
but the BERs don't know that |
| 18:47 |
|
fumanchu |
so many libs that offer to save dev time but cost equally in integration time and then add poor performance on top |
| 18:48 |
|
whartung |
si |
| 18:48 |
|
whartung |
I did a good effort to look |
| 18:48 |
|
sfisque |
aye. the issue gets dicey when you get blocks that have contiuations (like for large blobs) and stuff |
| 18:48 |
|
sfisque |
atomic types are trivial from what i remember. it's the complex types that can trip up |
| 18:48 |
|
whartung |
THere's Apache DS, but that's stuff is to tight it's impossible to dig it out -- and we EMPLOY a committer to the project! |
| 18:48 |
|
whartung |
SearchRequset is a hoot! |
| 18:49 |
|
sfisque |
i bet |
| 19:52 |
|
|
Sickness[] joined #rest |
| 19:52 |
|
|
Sickness[] left #rest |
| 19:59 |
|
|
eschmidbauer joined #rest |
| 20:15 |
|
|
quimrstorres joined #rest |
| 20:50 |
|
|
Doc-Saintly joined #rest |
| 20:51 |
|
Doc-Saintly |
What is the design pattern for REST with OIDC? Does the client get the auth token and pass it along to the REST service each time, and the REST service looks up the user information each time? |
| 20:53 |
|
whartung |
what's OIDC? |
| 21:11 |
|
Doc-Saintly |
OpenID Connect |
| 21:11 |
|
Doc-Saintly |
(Or OAuth 2 flows + authentication) |
| 21:13 |
|
whartung |
Oh, ok. |
| 21:13 |
|
whartung |
yea the rest service looks up the info each time. |
| 21:13 |
|
Doc-Saintly |
seems expensive :S |
| 21:13 |
|
whartung |
it is :0 |
| 21:13 |
|
whartung |
:) |
| 21:14 |
|
whartung |
if you pay attention, EVERYTHING in REST is expensive. |
| 21:14 |
|
Doc-Saintly |
So, is it not done commonly? |
| 21:14 |
|
whartung |
caching makes things "less expensive: |
| 21:14 |
|
whartung |
so, in truth most folks will cache things like that locally. |
| 21:14 |
|
whartung |
"yea, we just say this guy 4 microseconds ago..." |
| 21:14 |
|
whartung |
*saw |
| 21:15 |
|
Doc-Saintly |
hmmm, so I suppose in the JWT I could store the roles that are important, and just reference the token (because I trust it) and not go look up the user and see their roles each time? |
| 21:15 |
|
Doc-Saintly |
or would I not trust the roles in the KWT? |
| 21:15 |
|
Doc-Saintly |
JWT* |
| 21:17 |
|
whartung |
JWT? |
| 21:17 |
|
whartung |
but "yes", basically |
| 21:17 |
|
Doc-Saintly |
Javascript Web Token |
| 21:17 |
|
whartung |
give it some reasonable time to live (10s, 1m, 10m, whatever) |
| 21:17 |
|
whartung |
I don't know where in the workflow you get the actual user id for the requestor |
| 21:18 |
|
Doc-Saintly |
True. Well, basically I've made a round based game via REST service. |
| 21:18 |
|
whartung |
but at that point, it's 99.9999% safe to cache the higher level meta data (name, email, roles) |
| 21:18 |
|
|
shrink0r joined #rest |
| 21:18 |
|
Doc-Saintly |
So I can call "makeMove" for a player and it makes the move they specify. but, now I need to secure it and only let registered players make moves, and only on their account - obviously. |
| 21:19 |
|
Doc-Saintly |
so I can authenticate them, and authorize them to make moves, and then pass this token to the REST service which would just look at the name of the player, and that they can make moves, and then do the rest without looking things up - yes? |
| 21:19 |
|
Doc-Saintly |
Does the whole OAuth / OpenID pipeline handle making sure that the token hasen't been forged? Or does my back-end have to do that by auth'ing with what's in the token and looking up the details. |
| 21:21 |
|
whartung |
I'm not intimate enough with OpnID to say when the enforcement happens, and it depends on what you mean by "forged", but to a point it's "in there somewhere". |
