| Time |
S |
Nick |
Message |
| 01:36 |
|
|
happyface joined #rest |
| 01:48 |
|
|
shrink0r joined #rest |
| 01:53 |
|
|
SlippinJimmy joined #rest |
| 02:13 |
|
|
lemur_ joined #rest |
| 02:30 |
|
|
tieTYT2 joined #rest |
| 04:44 |
|
|
meric joined #rest |
| 04:49 |
|
meric |
From my understanding of rest - if I’m building a REST api client website - if I want to GET multiple resources to render the page, I *must* make multiple http requests, and connections to the REST api server. Is that correct? Is there a protocol whereby I can send something like https://gist.github.com/meric/5971e92440512fbc479e, and have the server return multiple responses stored in respective keys, reducing the cost on the network? For that example it wou |
| 04:49 |
|
meric |
mean 1 request and 1 response instead of 3 requests and 3 responses. |
| 05:00 |
|
meric |
I see the GraphAPI has it’s own protocol. https://developers.facebook.com/docs/graph-api/making-multiple-requests |
| 05:03 |
|
meric |
There’s even a library for it in django https://github.com/tanwanirahul/django-batch-requests, but it uses a different protocol |
| 06:49 |
|
|
tr3online joined #rest |
| 06:50 |
|
|
tr3online joined #rest |
| 06:50 |
|
|
tr3online joined #rest |
| 06:51 |
|
|
tr3online joined #rest |
| 06:54 |
|
|
tr3online joined #rest |
| 06:54 |
|
|
tr3online joined #rest |
| 06:55 |
|
|
tr3online joined #rest |
| 06:57 |
|
|
tr3online joined #rest |
| 06:59 |
|
|
tr3online joined #rest |
| 07:04 |
|
|
tr3online joined #rest |
| 07:05 |
|
|
tr3online joined #rest |
| 07:13 |
|
|
tr3online joined #rest |
| 07:22 |
|
trygvis |
meric: if you want to follow the architecture you often end up with n+1 requests |
| 07:22 |
|
trygvis |
but the payback is supposed to come the next time as the data is cached |
| 07:23 |
|
trygvis |
but there is nothing stopping you from going all rpc over http :) |
| 07:23 |
|
trygvis |
you could also make a media type that describes how to do batch-requests that tries to cover the consequencse |
| 07:25 |
|
meric |
trygvis: http://www.odata.org/documentation/odata-version-3-0/batch-processing/ :) |
| 07:26 |
|
meric |
I found that just now microsoft invented the “multipart/mixed" |
| 07:51 |
|
trygvis |
doesn't seem like they did it: http://www.rfc-editor.org/rfc/rfc2046.txt |
| 08:14 |
|
|
tr3online joined #rest |
| 08:21 |
|
|
igitoor joined #rest |
| 08:31 |
|
|
igitoor joined #rest |
| 08:32 |
|
|
vanHoesel joined #rest |
| 08:45 |
|
|
graste joined #rest |
| 09:37 |
|
|
Left_Turn joined #rest |
| 09:40 |
|
|
shrink0r joined #rest |
| 09:44 |
|
|
tr3online joined #rest |
| 09:51 |
|
|
mezod joined #rest |
| 10:14 |
|
|
tr3online joined #rest |
| 10:18 |
|
|
tr3online joined #rest |
| 10:27 |
|
|
tr3online joined #rest |
| 10:40 |
|
|
tr3online joined #rest |
| 10:43 |
|
|
tr3online joined #rest |
| 10:44 |
|
|
tr3online joined #rest |
| 10:50 |
|
|
tr3online joined #rest |
| 11:01 |
|
|
Left_Turn joined #rest |
| 11:49 |
|
|
tr3online joined #rest |
| 12:26 |
|
|
mezod joined #rest |
| 12:49 |
|
|
tr3online joined #rest |
| 14:04 |
|
|
tr3online joined #rest |
| 14:27 |
|
|
wsiqueir joined #rest |
| 14:35 |
|
|
tr3online joined #rest |
| 14:36 |
|
|
64MACFJ1B joined #rest |
| 15:02 |
|
|
dEPy joined #rest |
| 15:12 |
|
|
tr3online joined #rest |
| 15:39 |
|
|
jcromartie joined #rest |
| 15:42 |
|
|
tr3online joined #rest |
| 15:44 |
|
|
Andre-B joined #rest |
| 15:48 |
|
|
tr3online joined #rest |
| 15:53 |
|
|
tr3online joined #rest |
| 16:14 |
|
|
tr3online joined #rest |
| 16:36 |
|
|
lemur joined #rest |
| 17:11 |
|
|
tr3online joined #rest |
| 17:12 |
|
|
tr3online joined #rest |
| 17:13 |
|
|
tr3online joined #rest |
| 17:16 |
|
|
7YUAAPQCB joined #rest |
| 17:39 |
|
t_dot_zilla |
when updating with PUT? do you put the data in headers or query params? |
| 17:40 |
|
t_dot_zilla |
or is PUT used to create and POST used to update? |
| 17:40 |
|
whartung |
PUT is used to create or replace the resource |
| 17:40 |
|
whartung |
the data should be in the actual payload of the message |
| 17:42 |
|
t_dot_zilla |
what should be used to update only certain aspects of a resource? |
| 17:42 |
|
whartung |
simple replace the resource wholesale |
| 17:43 |
|
pdurbin |
or use PATCH, maybe |
| 17:43 |
|
|
hackel joined #rest |
| 17:43 |
|
t_dot_zilla |
whartung: okay so always replace the entire resource |
| 17:44 |
|
t_dot_zilla |
right? |
| 17:44 |
|
trygvis |
that is usually the best strategy |
| 17:45 |
|
whartung |
no, never "always" do anything. Evaluate the circumstances of your use case given all of the criteria involved, and then make your best determination for the outcome. Replacing the entire resource is a viable technique. But if you're updating 1GB resource with 10bytes of information, maybe that's not that best idea. |
| 17:45 |
|
t_dot_zilla |
whartung: understood. the payload should be in json format? |
| 17:45 |
|
whartung |
it shoudl be whatever format is appropriate for the representation of your resource |
| 17:46 |
|
t_dot_zilla |
im outputting in json |
| 17:46 |
|
whartung |
then json sounds like a good idea in this case |
| 17:46 |
|
t_dot_zilla |
thanks |
| 17:46 |
|
whartung |
yw |
| 17:47 |
|
t_dot_zilla |
is it important to check the content-type header to make sure it's application/json? |
| 17:47 |
|
whartung |
well, it can be handy, but I'm sure you're going to find out when you try to parse the json whether the header is actually accurate, right? So, that's up to you |
| 17:48 |
|
t_dot_zilla |
yeah, youre right |
| 17:55 |
|
fumanchu |
if you ever want to support other media types, it's a good practice. you can (depending on your HTTP server) reject a large message based on the headers before receiving the whole thing and trying to parse it (which you can't do with JSON in particular until you have the whole document) |
| 17:56 |
|
t_dot_zilla |
for my platform, i won't ever be sending large files or documents |
| 17:57 |
|
t_dot_zilla |
but i like to develop my system for any possibility so i will take that into consideration |
| 18:05 |
|
t_dot_zilla |
if PUT can be used for both "new" objects and "updating" what is POST ever used for? |
| 18:05 |
|
t_dot_zilla |
it's difficult to understand which one to use for what types of scenarios |
| 18:05 |
|
t_dot_zilla |
i understand GET/DELETE (they are straightforward) |
| 18:13 |
|
|
tr3online joined #rest |
| 18:14 |
|
t_dot_zilla |
should 201 only be returned for 'creating' or can it be used for 'updating'? |
| 18:14 |
|
t_dot_zilla |
in other words, if update is successful, should it return 200 or 201 |
| 18:14 |
|
t_dot_zilla |
? |
| 18:17 |
|
t_dot_zilla |
also, is it common practice to return the payload (or body) update success of create/update? |
| 18:18 |
|
trygvis |
it's up to you |
| 18:18 |
|
trygvis |
also choosing between 200 and 201 |
| 18:19 |
|
t_dot_zilla |
i find REST amazing, yet there are no standards. seems like as long as you doc everything you create "anything goes" type of system |
| 18:20 |
|
trygvis |
well, it's is an *architectural style*. so you are expected to create your own architecture |
| 18:21 |
|
trygvis |
but it is also implicitly a networked system so it should also follow this: https://en.wikipedia.org/wiki/Robustness_principle |
| 18:26 |
|
t_dot_zilla |
thanks trygvis |
| 18:36 |
|
pdurbin |
t_dot_zilla: generally, POST is used to create and PUT is used to replace: http://en.wikipedia.org/wiki/Representational_state_transfer#Example |
| 18:36 |
|
t_dot_zilla |
pdurbin: thanks |
| 18:37 |
|
fumanchu |
pdurbin: only if the client is not supposed to supply the (id part of the) URI |
| 18:37 |
|
pdurbin |
the devil is in the details :) |
| 18:39 |
|
fumanchu |
t_dot_zilla: don't return 201 for an update; only for creating a new resource. |
| 18:49 |
|
|
Andre-B joined #rest |
| 19:24 |
|
|
shrink0r_ joined #rest |
| 20:05 |
|
|
Andre-B_ joined #rest |
| 20:27 |
|
|
cigarshark joined #rest |
| 20:35 |
|
|
graste joined #rest |
| 20:37 |
|
|
shrink0r joined #rest |
| 21:05 |
|
|
shrink0r_ joined #rest |
| 21:51 |
|
|
vanHoesel joined #rest |
| 21:58 |
|
vanHoesel |
t_dot_zilla: for what it's worth - but helps to make your api extensible to the future... i would check the Content-Type request header to see if it is actually the format you want and the api understands --- if it's not appication/json, return 415 --- in the future you can add application/xml without aving it default to anything , have your client explicitly declare wht it is sending |
| 22:21 |
|
|
vanHoesel joined #rest |
| 23:52 |
|
|
meric joined #rest |
