| Time |
S |
Nick |
Message |
| 00:02 |
|
|
SlippinJimmy joined #rest |
| 00:03 |
|
|
azr joined #rest |
| 00:20 |
|
pdurbin |
whartung: similar problems in #io: http://irclogs.shortcircuit.net.au/%23io/2015-03-17.log.html#t23:41:35 :) |
| 00:20 |
|
pdurbin |
and sure to get worse now that io.js is a thing |
| 00:21 |
|
whartung |
heh |
| 00:48 |
|
|
ralphschindler joined #rest |
| 01:00 |
|
|
ralphschindler joined #rest |
| 01:22 |
|
|
ralphschindler joined #rest |
| 01:57 |
|
|
shrink0r_ joined #rest |
| 02:32 |
|
|
lemur joined #rest |
| 03:23 |
|
|
fumanchu joined #rest |
| 03:51 |
|
|
dkm joined #rest |
| 03:51 |
|
|
ralphschindler joined #rest |
| 04:43 |
|
|
ralphschindler joined #rest |
| 06:20 |
|
|
tr3online joined #rest |
| 07:22 |
|
|
Andre-B joined #rest |
| 07:54 |
|
|
vanHoesel joined #rest |
| 08:30 |
|
|
Andre-B joined #rest |
| 08:38 |
|
Andre-B |
should a bad request response only contain http status code 400 and message bad request, or can I have a message like bad request: missing filter param - to indicate what’s bad on that request? |
| 08:42 |
|
|
vanHoesel joined #rest |
| 09:04 |
|
|
azr joined #rest |
| 09:31 |
|
|
Andre-B_ joined #rest |
| 09:33 |
|
|
_ollie joined #rest |
| 09:44 |
|
|
vanHoesel joined #rest |
| 09:53 |
|
|
shrink0r joined #rest |
| 10:16 |
|
pdurbin |
Andre-B: for our Search API we return 400 and {"status":"ERROR","message":"q parameter is missing"} |
| 10:19 |
|
pdurbin |
huh. github returns a 422 at https://api.github.com/search/repositories 422 Unprocessable Entity ... it says "message": "Validation Failed" (and has an array of errors with "q... missing") |
| 10:20 |
|
trygvis |
pdurbin: githubs api has a lot of strange stuff |
| 10:23 |
|
trygvis |
Andre-B: you can include whatever you want in your response, it's just like any other response. make sure to include a proper content-type so the client knows how to process it |
| 10:23 |
|
trygvis |
like pdurbin does :) |
| 10:26 |
|
pdurbin |
When you write your own API you can fill it with strange stuff. :) |
| 10:32 |
|
trygvis |
yep |
| 10:38 |
|
|
vanHoesel joined #rest |
| 10:47 |
|
|
vanHoesel joined #rest |
| 11:52 |
|
|
Left_Turn joined #rest |
| 12:54 |
|
|
azr joined #rest |
| 13:15 |
|
|
StatelessCat joined #rest |
| 13:32 |
|
|
mezod joined #rest |
| 13:35 |
|
|
azr joined #rest |
| 14:29 |
|
|
ralphschindler joined #rest |
| 14:46 |
|
|
Andre-B_ joined #rest |
| 15:06 |
|
|
ralphschindler joined #rest |
| 15:16 |
|
|
happyface joined #rest |
| 16:01 |
|
|
shrink0r joined #rest |
| 16:03 |
|
|
lemur joined #rest |
| 16:40 |
|
|
TeddyMurray joined #rest |
| 16:40 |
|
TeddyMurray |
anyone know any good coupon RESTful databases? |
| 16:50 |
|
|
tr3online joined #rest |
| 16:53 |
|
_ollie |
what's a restful database? |
| 16:54 |
|
fumanchu |
what's a (for each term in combinations(["good", "coupon", "RESTful", "database"]))? |
| 17:55 |
|
|
fumanchu_ joined #rest |
| 18:03 |
|
|
t_dot_zilla joined #rest |
| 18:03 |
|
t_dot_zilla |
hello |
| 18:05 |
|
t_dot_zilla |
I'm trying to understand how to implement a secure RESTful API |
| 18:05 |
|
t_dot_zilla |
i have the API setup like this tutorial http://www.androidhive.info/2014/01/how-to-create-rest-api-for-android-app-using-php-slim-and-mysql-day-12-2/ |
| 18:05 |
|
t_dot_zilla |
which basically retrieves the apikey based on a valid user/pass login |
| 18:06 |
|
t_dot_zilla |
the api-key is then used for authentication on all other functions |
| 18:06 |
|
t_dot_zilla |
from an client application standpoint. would the api-key be stored in a 'cookie' ? |
| 18:07 |
|
t_dot_zilla |
is that secure? assuming everything is done via https |
| 18:08 |
|
pdurbin |
you've got to store it somewhere |
| 18:08 |
|
t_dot_zilla |
if you were using a website -> api. would a cookie make sense? or perhaps a php session more sense? |
| 18:09 |
|
t_dot_zilla |
website being the client app |
| 18:09 |
|
pdurbin |
you could store the api key in a database |
| 18:09 |
|
t_dot_zilla |
right it is stored in the database |
| 18:09 |
|
t_dot_zilla |
the client retrieves it with the correct user/pass hash |
| 18:10 |
|
t_dot_zilla |
then the client uses the api-key to perform other functions (instead of having to re-auth with user/passhash each request) |
| 19:38 |
|
|
adaro joined #rest |
| 20:08 |
|
|
Davey joined #rest |
| 20:16 |
|
|
tr3online joined #rest |
| 20:36 |
|
|
Left_Turn joined #rest |
| 20:53 |
|
|
tr3online joined #rest |
| 21:17 |
|
|
warehouse13 joined #rest |
| 23:08 |
|
|
talios joined #rest |
| 23:19 |
|
warehouse13 |
hey which is a better json response? https://bpaste.net/show/dec769180af2 |
| 23:20 |
|
asdf` |
warehouse13, i'm not sure why would that matter, but sure, i guess i'd do the latter (also that's javascript, not json) |
| 23:22 |
|
warehouse13 |
well that will be the object before it's serialised... I was just trying to get a good format so I could also have it represented well in sql and also the rest library I use |
| 23:22 |
|
warehouse13 |
@ asdf` |
| 23:24 |
|
whartung |
you should focus on the resource design itself, and worry about how its implemented later |
| 23:25 |
|
warehouse13 |
you're right |
| 23:25 |
|
warehouse13 |
I keep thinking ahead:( haven't designed an api before |
| 23:42 |
|
pdurbin |
nothing wrong with thinking ahead |
