Hello there,
so far Ive been able to replace/manipulate the code of a whole room with the HTTP API, and in order to manipulate single objects Ive used the Websocket API.
I wonder if it is possible to at least add things via HTTP API or even changing particular things in the json.
Is there a way to do that?
Thanks in advance!
Could you elaborate on what you mean by “add things via HTTP API?”
Okay.
So far, Ive used the HTTP API to replace the whole code of a room. Which means, if a webhook got triggered. It sended ALL room informations with the SetMap API including Tiles and Objects that arent affected by the action.
What I was looking for, is a way to patch the code instead of push.
E.g. if I want an Object to appear/disappear as soon as Gforms has been submitted. I want to replace only the Object Image, not the whole code.
It means Gather.town should develop new endpoints for HTTP API.
It would be great !
Is there a particular reason why the HTTP endpoints are more desireable for your usecase than the websocket?
Oh I love the websocket it’s really nice working with it.
The http api, from my understanding, is more useable for low/no-coding things. Which is especially for enablement of some clients really important.
So I may get a little long winded here, but I will try to be brief and just lay out some interesting observations:
The Websocket API can do almost everything that the HTTP API can do. It is also far more flexible than the HTTP API.
The HTTP API can currently do 3 things the WS-API cannot: create spaces, create new rooms in a space, and manipulate the guestlist. In a different world, Gather would abandon all endpoints that the Websocket can do better, and only leave the HTTP API for calls and commands they wanted to keep separate. This would avoid redundancy in the system, and avoid having to upkeep two different ways of doing things.
With the websocket, any developer can create their own psudo-HTTP API to expose to their client. I could create an endpoint, for example, that went in and caused everyone to dance, or that caused all the objects in one area to shuffle around, etc. All you would need is a hosting platform that allowed you to run an Express App, or any of the other backend dev tools.
Is that level of flexibility not ultimately desired for a platform like this? Where developers can produce and use endpoints specific to their clients instead of having to wait for Gather to produce an endpoint that does something the WS-API can handle? Isn’t this a hugely value added element of developing integrations for Gather?
In closing, it almost seems like asking for new HTTP API endpoints would be better served with some specifics as to the purpose, and a reason the Websocket cannot handle it.
In a perfect world, someone (or Gather) would put together a “Build-Your-Own API for Gather” Git repository or something, to get people headed in that direction.
Anyway, just my thoughts on the matter.
As an amateur developer with no experience with node.js and stuff like that 
, the HTTP API is great to start intercating with gather spaces. And I don’t have a server to host active servers like xxxxx.js 
(but I found a post regarding Heroku that is a lead!)
I found out that I mainly use the objects, portals and collisions parts on a room map. With theses three direct endpoints, it would be great
Without them, I have to learn using the websocket API. Learning is great, but since dev is one of my hobby (among many others), I’m happy if it’s simple 
and not too heavy learning !
@Bill_Uncork-It , Thank you for the detailed presentation of your opinion and thoughts on the subject.
From the perspective of an experienced web developer, this may all be true. But HTTP API offers MANY possibilities without having to understand any code at all. And this is a hurdle that allows many people to do exciting and helpful experiments in Gather. I have some clients who don’t want to learn about websocket, node.js, heroku etc. before doing simple manipulations to their Gather.Town space.
So I think in the future we should carefully distinguish between things that can be done with HTTP API and things that could be done with HTTP API but are better done with websocket.
Your work and projects with the Websocket API are a nice inspiration and motivation for me to continue with it, until then I’m happy when my brother @Patrick takes over such work as an experienced web developer. Personally, I often have more questions than answers when using the websocket API, which makes it quite time-consuming for me. I often reach my goal faster with the simple HTTP API.