| Time |
S |
Nick |
Message |
| 00:15 |
|
|
mezod joined #rest |
| 01:15 |
|
|
wsiqueir joined #rest |
| 01:46 |
|
|
baweaver joined #rest |
| 02:47 |
|
|
quimrstorres joined #rest |
| 04:48 |
|
|
dEPy joined #rest |
| 04:48 |
|
dEPy |
yo |
| 04:49 |
|
dEPy |
what does everyone think of pagination in header vs pagination in response body like: pagination: {prev: ..., next: ...} |
| 04:49 |
|
dEPy |
? |
| 05:28 |
|
|
Macaveli joined #rest |
| 05:45 |
|
|
quimrstorres joined #rest |
| 07:33 |
|
|
alexnyq joined #rest |
| 07:35 |
|
alexnyq |
When you expose enum values through an API, do you make it a responsibility of the client or the server to convert that into a human readable string? For example, a customer may have a type indicating its level, {level: 'Gold'}. This may be the business equivalent of 'Step 3, Gold'. |
| 07:37 |
|
alexnyq |
I see a number of different approaches, returning {level: { value: 'Gold', desc: 'Step 3, Gold' } }. Exposing /levels/ as a resource where the client can find the readable string, or have the client just switch on the returned value. However, that means maintaining the descriptions in multiple places. |
| 07:48 |
|
|
nesselbosch joined #rest |
| 08:16 |
|
|
rosstuck joined #rest |
| 08:21 |
|
|
timg___ joined #rest |
| 09:32 |
|
|
interop_madness joined #rest |
| 09:42 |
|
|
baweaver joined #rest |
| 10:10 |
|
|
quimrstorres joined #rest |
| 10:14 |
|
|
Andre-B joined #rest |
| 10:25 |
|
|
quimrstorres joined #rest |
| 10:27 |
|
|
quimrstorres joined #rest |
| 10:35 |
|
|
quimrstorres joined #rest |
| 10:45 |
|
|
quimrsto_ joined #rest |
| 10:55 |
|
|
quimrstorres joined #rest |
| 11:00 |
|
daxim |
you make it into the responsibility of the server because of conneg: Accept-Language: la ……… { "_links" : { "self" : { "href" : "/levels/gold", "title" : "passus tertius, aurum" } } } |
| 11:00 |
|
daxim |
I'm using hal+json here. if you construct the responses properly, you only need to have the descriptions once in a single place in your server-side code. |
| 11:23 |
|
alexnyq |
Thx daxim, sounds like a good solution. |
| 11:57 |
|
|
quimrstorres joined #rest |
| 11:58 |
|
|
quimrsto_ joined #rest |
| 12:09 |
|
|
quimrstorres joined #rest |
| 12:14 |
|
|
Andre-B_ joined #rest |
| 12:23 |
|
|
baweaver joined #rest |
| 12:29 |
|
|
quimrstorres joined #rest |
| 12:37 |
|
|
quimrstorres joined #rest |
| 12:48 |
|
|
quimrstorres joined #rest |
| 12:58 |
|
|
quimrsto_ joined #rest |
| 13:09 |
|
|
quimrstorres joined #rest |
| 13:19 |
|
|
quimrsto_ joined #rest |
| 13:30 |
|
|
quimrstorres joined #rest |
| 13:31 |
|
|
mezod joined #rest |
| 13:51 |
|
|
quimrstorres joined #rest |
| 14:01 |
|
|
quimrstorres joined #rest |
| 14:12 |
|
|
quimrstorres joined #rest |
| 14:22 |
|
|
quimrsto_ joined #rest |
| 14:24 |
|
|
baweaver joined #rest |
| 14:25 |
|
|
quimrstorres joined #rest |
| 14:37 |
|
|
quimrstorres joined #rest |
| 14:51 |
|
|
mezod joined #rest |
| 14:58 |
|
|
quimrstorres joined #rest |
| 15:07 |
|
|
sulky joined #rest |
| 15:25 |
|
|
saml joined #rest |
| 15:30 |
|
|
quimrsto_ joined #rest |
| 15:41 |
|
|
quimrstorres joined #rest |
| 15:45 |
|
|
bluezone joined #rest |
| 15:58 |
|
|
quimrstorres joined #rest |
| 16:12 |
|
|
quimrstorres joined #rest |
| 16:25 |
|
|
baweaver joined #rest |
| 16:31 |
|
|
quimrstorres joined #rest |
| 16:47 |
|
|
damonkelley joined #rest |
| 16:52 |
|
|
quimrstorres joined #rest |
| 17:14 |
|
|
quimrstorres joined #rest |
| 17:25 |
|
|
quimrstorres joined #rest |
| 17:35 |
|
|
quimrstorres joined #rest |
| 17:48 |
|
|
quimrstorres joined #rest |
| 17:52 |
|
|
baweaver joined #rest |
| 17:58 |
|
|
quimrstorres joined #rest |
| 18:09 |
|
|
quimrstorres joined #rest |
| 18:19 |
|
|
quimrstorres joined #rest |
| 18:30 |
|
|
quimrstorres joined #rest |
| 18:41 |
|
|
quimrstorres joined #rest |
| 18:53 |
|
|
baweaver joined #rest |
| 19:25 |
|
|
Macaveli joined #rest |
| 19:49 |
|
|
quimrstorres joined #rest |
| 20:53 |
|
|
baweaver joined #rest |
| 21:40 |
|
|
graste joined #rest |
| 21:41 |
|
|
tbsf joined #rest |
| 21:42 |
|
tbsf |
Is it a good idea to allow clients to set timeouts for resources your rest api calls? |
| 21:45 |
|
pdurbin |
tbsf: you make it sound like a rest api is calling resources. I'd say it *has* resources. I'm not sure what you're asking. |
| 21:46 |
|
tbsf |
Like if it's going to a database, should I specify how long the API should wait for the query to return? |
| 21:49 |
|
pdurbin |
oh |
| 21:49 |
|
pdurbin |
if you want, I guess |
| 21:50 |
|
pdurbin |
or be_patient=1 :) |
| 21:55 |
|
tbsf |
I guess the benefit is that if the client is not going to wait that long, it times out |
| 21:56 |
|
tbsf |
And we're not doing the query for no reason |
| 21:56 |
|
daxim |
it's perfectly fine to lower the timeout on your HTTP client, the defaults are usually quite long. this is a matter of TCP though, not HTTP or REST |
| 21:59 |
|
tbsf |
but should my client pass a timeout parameter to tell the REST api how long it will wait? |
| 22:00 |
|
fumanchu |
typically, no. you don't want to give most clients that much power over your system |
| 22:00 |
|
|
tbsf joined #rest |
| 22:00 |
|
fumanchu |
set internal timeouts based on what the server needs to stay responsive |
| 22:02 |
|
|
tbsf joined #rest |
| 22:12 |
|
|
standardguy joined #rest |
| 22:43 |
|
|
tbsf joined #rest |
| 22:53 |
|
|
mezod joined #rest |
| 22:57 |
|
|
tbsf joined #rest |
| 23:02 |
|
|
tbsf joined #rest |
