| Time |
S |
Nick |
Message |
| 00:22 |
|
|
fuzzyhorns joined #rest |
| 01:06 |
|
|
foist joined #rest |
| 01:06 |
|
foist |
Is it non-standard to omit keys from the response body if the value of those keys is null? |
| 01:17 |
|
|
fuzzyhorns joined #rest |
| 01:28 |
|
pdurbin |
foist: not sure, but we do that |
| 01:28 |
|
foist |
pdurbin: it has been suggested to me that it’s a bad practice. |
| 01:28 |
|
foist |
I’m hunting for something to confirm or dispute the suggestion. |
| 01:28 |
|
pdurbin |
whoops |
| 01:29 |
|
pdurbin |
nobody has complained |
| 03:12 |
|
|
ShekharReddy joined #rest |
| 04:39 |
|
|
fuzzyhorns joined #rest |
| 05:00 |
|
|
Coldblackice joined #rest |
| 05:09 |
|
|
Coldblackice_ joined #rest |
| 05:12 |
|
|
wsieroci joined #rest |
| 07:14 |
|
|
graste joined #rest |
| 07:36 |
|
|
Macaveli joined #rest |
| 08:15 |
|
|
Tomatosoup- joined #rest |
| 08:34 |
|
|
graste1 joined #rest |
| 09:08 |
|
|
DevAntoine joined #rest |
| 09:08 |
|
DevAntoine |
hi |
| 09:08 |
|
DevAntoine |
When patching an object I'm not sure how to behave for collections. Let's say I've got a Site and a collection of Building. Should the client passes all the buildings each time or just the new ones? If the client only passes the new ones, how can he removes existing Building from the Site? |
| 09:14 |
|
Tomatosoup- |
each site have multiple buildings, right ? |
| 09:15 |
|
DevAntoine |
yep |
| 09:15 |
|
DevAntoine |
in fact I don't know how to handle relationships the rest way |
| 09:18 |
|
Tomatosoup- |
/site/{site_id}/buildings -> that should list all the buildings from given site |
| 09:18 |
|
DevAntoine |
should the client be able to create a new building directly by passing all the Building data in the Site data? |
| 09:18 |
|
Tomatosoup- |
GET /site/{site_id}/buildings/{building_id} -> and that should retreive one particular building |
| 09:19 |
|
DevAntoine |
Tomatosoup-: I've got no issue with GET, it's POST which troubles me |
| 09:19 |
|
Tomatosoup- |
client should be able to create new building connected with particular Site through making request: POST /site/{site_id}/buildings |
| 09:20 |
|
Tomatosoup- |
DevAntoine: i understand, but the thing is that since you should support all http verbs, it is all about URIs |
| 09:20 |
|
DevAntoine |
{'siteName': 'Foo', buildings: [13, 42]} or {'siteName': 'Foo', buildings: [{'name': 'Building name1'}, {'name': 'Building name2'}} ? |
| 09:21 |
|
DevAntoine |
Tomatosoup-: they can't create building directly when creating a Site? |
| 09:22 |
|
Tomatosoup- |
they can, thats up to you - but adding new building to existing site should be in a way that i proposed |
| 09:22 |
|
Tomatosoup- |
DevAntoine: at which URI you would like to have such response? |
| 09:22 |
|
DevAntoine |
Tomatosoup-: what I mean is "they can't in the same POST"? |
| 09:23 |
|
DevAntoine |
They can't embed the data of a new building in the data of a Site when POST? |
| 09:23 |
|
Tomatosoup- |
they can |
| 09:24 |
|
DevAntoine |
Tomatosoup-: how so? |
| 09:24 |
|
Tomatosoup- |
its up to your implementation |
| 09:24 |
|
DevAntoine |
I'd like to see what the JSON of a Site with associated Building would looks like when adding existing building to the Site and new Building too |
| 09:25 |
|
Tomatosoup- |
when adding existing building, you should just pass id to `buildings` -> like you already presented {'siteName': 'Foo', buildings: [13, 42]} |
| 09:26 |
|
DevAntoine |
I agree with that yes |
| 09:26 |
|
Tomatosoup- |
when adding new building to existing site, you should do that via POST /sites/{site_id}/buildings/ |
| 09:26 |
|
DevAntoine |
Tomatosoup-: yes, a separate POST! |
| 09:26 |
|
Tomatosoup- |
thats it |
| 09:27 |
|
DevAntoine |
I can't create a building in the same POST request than the Site |
| 09:27 |
|
Tomatosoup- |
it depends, if you create site, or update site ? |
| 09:27 |
|
DevAntoine |
updat |
| 09:27 |
|
DevAntoine |
e |
| 09:27 |
|
Tomatosoup- |
so the answer is no, you cant |
| 09:27 |
|
Tomatosoup- |
it isnt SOAP :) |
| 09:28 |
|
Tomatosoup- |
(god bless) |
| 09:29 |
|
DevAntoine |
because currently that's what I have. I can create Building directly in the Site JSON but what happens it that you have to pass the entire Buildings data in each POST. You can't pass IDs (because I can't deal with IDs and/or Building) but you have to pass all the associated Buildings data each time. If not, the Buildings get removed |
| 09:30 |
|
Tomatosoup- |
you should use POST to create resource, and PUT/PATCH to update (generalizing) |
| 09:31 |
|
DevAntoine |
Tomatosoup-: that's what I'm doing, I said POST but it's a PATCH |
| 09:32 |
|
Tomatosoup- |
well, then something wrong is with your implementation |
| 09:32 |
|
DevAntoine |
yes, I agree |
| 09:32 |
|
DevAntoine |
I won't let creation of nested objects. The client could only passes IDs of nested objects |
| 09:32 |
|
DevAntoine |
that feels better? |
| 09:34 |
|
Tomatosoup- |
ideally, client also should be able to create nested objects during object creation (creation, not update) |
| 09:35 |
|
DevAntoine |
Tomatosoup-: and how to mix creation and selection? If the client wants to associate to the Site an existing Building and a new one, how it'd look like? |
| 09:35 |
|
DevAntoine |
Tomatosoup-: is it still a separate POST for the creation and then passing the newly created Building's ID to the Site data? |
| 09:37 |
|
Tomatosoup- |
is building name unique ? |
| 09:37 |
|
DevAntoine |
Tomatosoup-: nop |
| 09:39 |
|
Tomatosoup- |
you can implement something like: get_or_create() - when passing building properties, at first try to get existing building, if it returns none, it should create new building |
| 09:40 |
|
DevAntoine |
so the JSON would looks like this? {'siteName': 'Foo', buildings: [{'name': 'Building name1'}, 13, 20} ? |
| 09:44 |
|
Tomatosoup- |
i thought of something like this: {'siteName': 'Foo', buildings: [{'name': 'Building name1'}, {'name': 'Building name2'}] |
| 09:44 |
|
Tomatosoup- |
and if Building name2 already exists, it just add it |
| 09:45 |
|
Tomatosoup- |
but the thing is that you have to pass some unique data to specify this building |
| 09:45 |
|
DevAntoine |
Tomatosoup-: and what if my Building has way lot more data |
| 09:45 |
|
Tomatosoup- |
if you know that for example bulding_id=20 exists, your solution is absolutely legit |
| 09:46 |
|
DevAntoine |
Tomatosoup-: I can mix IDs and whole data? |
| 09:48 |
|
DevAntoine |
and then I don't know how I should remove a Building from the Site |
| 09:48 |
|
Tomatosoup- |
hm, that obviously would work, but im not sure if it is actually restful |
| 09:48 |
|
Tomatosoup- |
DevAntoine: DELETE /site/{site_id}/buildings/{building_id}/ |
| 09:49 |
|
DevAntoine |
Tomatosoup-: so a big form (let's say one main entity and 6 nested entities) would make a lot of calls to the api? |
| 09:50 |
|
Tomatosoup- |
what do you mean by 'lot of calls'? |
| 09:51 |
|
DevAntoine |
Tomatosoup-: well, some calls to delete Buildings, others to create Buildings, other calls to do the same thing with other nested objects and the final PATCH call to edit the Site |
| 09:54 |
|
Tomatosoup- |
you can actually squeeze everything into one PATCH, if you contain all the necessary data within it |
| 09:55 |
|
DevAntoine |
Tomatosoup-: I don't see how I can handle the Building creation, Building association and Building unassciation in one PATCH |
| 10:00 |
|
Tomatosoup- |
you can if you patch override `buildings` |
| 10:00 |
|
Tomatosoup- |
s/you/your |
| 10:03 |
|
DevAntoine |
Tomatosoup-: so the client always has to pass the entire building list if he wants to keep the current association with Site. If he omits one Building the API decided to remove the association between this Building and this Site? |
| 10:11 |
|
Tomatosoup- |
either that what you said, or lot of calls to the api |
| 10:16 |
|
DevAntoine |
yeah, I still don't know what to do tbh :/ |
| 10:17 |
|
|
upasana joined #rest |
| 10:33 |
|
|
event15 joined #rest |
| 11:18 |
|
|
graste joined #rest |
| 14:27 |
|
mamund |
DevAntoine: not sure if you'r still here, but a very solid approach is to use PATCH and patch media types. |
| 14:27 |
|
mamund |
RFC 6902 is the JSON Patch media type. |
| 14:27 |
|
|
ShekharReddy joined #rest |
| 14:29 |
|
DevAntoine |
I'm not aware at all about patch media type |
| 15:06 |
|
|
wsiqueir joined #rest |
| 15:34 |
|
|
tbsf joined #rest |
| 15:35 |
|
|
tbsf joined #rest |
| 16:06 |
|
|
fuzzyhorns joined #rest |
| 16:39 |
|
|
wsieroci joined #rest |
| 17:03 |
|
|
foist joined #rest |
| 17:17 |
|
|
dougquaid joined #rest |
| 18:50 |
|
|
fuzzyhorns joined #rest |
| 19:07 |
|
|
wsieroci joined #rest |
| 19:08 |
|
|
wsieroci joined #rest |
| 19:20 |
|
|
Macaveli joined #rest |
| 19:48 |
|
|
wsieroci joined #rest |
| 20:12 |
|
mamund |
DevAntoine: there are two JSON PATCH formats (i think) and at least one XML-based patch format. |
| 20:12 |
|
mamund |
they include ways to add, update, remove, and (IIRC) move nodes in a object tree. |
| 20:14 |
|
mamund |
RFC 7351 us ibe if the XML falvors: https://tools.ietf.org/html/rfc7351 |
| 20:15 |
|
mamund |
the other JSON one is JSON Merge Patch : https://tools.ietf.org/html/rfc7386 |
| 20:16 |
|
mamund |
that's more than enough to be able to add solid support for PATCH in either JSON or XML. |
| 20:21 |
|
whartung |
there aren't universal implementations of it yet, though I don't beleive. It's mostly popular, but not universal |
| 21:58 |
|
|
tbsf joined #rest |
| 22:33 |
|
|
fuzzyhorns joined #rest |
