|
|
On 05/11/16 21:46, radar-2@squat.net wrote:
|
|
|
> The issue is that your API
|
|
|
> documentation doesn't look usable. What is it like?
|
|
|
|
|
|
Good timing I'm just making a 1.1 version now.
|
|
|
|
|
|
The 1.0 was very much changed at the last minute (after the original spect was written) to meet the demands of the few users at the time, all of whom were using the PHP client (or the WordPress plugin based on it), so rewrite of the documentation dropped down in the priority list.
|
|
|
|
|
|
So I pushed 1.1 to the site, as it stands. It's adding stuff that has come up since 1.0 - so if you have anything you can add now is a good time.
|
|
|
|
|
|
For fetching lists of data the most handy place are the search endpoints:-
|
|
|
|
|
|
https://radar.squat.net/api/1.1/search/events.json
|
|
|
https://radar.squat.net/api/1.1/search/groups.json
|
|
|
|
|
|
These give access to the solr searches you see on
|
|
|
https://radar.squat.net/en and https://radar.squat.net/en/groups
|
|
|
|
|
|
So as you will see in the json of the results you have
|
|
|
{
|
|
|
result: {}
|
|
|
count: {}
|
|
|
facets: {}
|
|
|
}
|
|
|
|
|
|
The result is a set of entities with the default fields.
|
|
|
|
|
|
You can change the fields returned by adding fields[] array like
|
|
|
|
|
|
https://radar.squat.net/api/1.1/search/groups.json?fields[]=title&fields[]=uuid
|
|
|
|
|
|
The count is the total number of possible results. The number of results returned defaults to the maximum limit of 500, you can lower this by adding limit
|
|
|
|
|
|
https://radar.squat.net/api/1.1/search/groups.json?fields[]=title&fields[]=uuid&limit=1
|
|
|
|
|
|
The facets is the nice bit.
|
|
|
|
|
|
facets: {
|
|
|
country: []
|
|
|
city: []
|
|
|
...
|
|
|
}
|
|
|
|
|
|
They are just the same (well there are some more) as on the search pages you saw above. The KEYS and FILTER values are the same too. So you can compose your filters from the front-end too:-
|
|
|
|
|
|
https://radar.squat.net/api/1.1/search/groups.json?facets[city][]=Barcelona
|
|
|
|
|
|
.. for the groups in Barcelona.
|
|
|
|
|
|
Now looking at the events. I'll look at Amsterdam, because the events there tend to be a bit more feature rich (I'll mention why in a later section).
|
|
|
|
|
|
Unsurprisingly the search is just:
|
|
|
|
|
|
https://radar.squat.net/api/1.1/search/events.json?facets[city][]=Amsterdam
|
|
|
|
|
|
but you'll now see the facets: {} for group appear (just as it does in the front end) so:
|
|
|
|
|
|
https://radar.squat.net/api/1.1/search/events.json?facets[city][]=Amsterdam&facets[group][]=41
|
|
|
|
|
|
are the events in https://radar.squat.net/en/events/city/Amsterdam/group/41
|
|
|
|
|
|
But you can also have all the events categorised as free:
|
|
|
|
|
|
https://radar.squat.net/api/1.1/search/events.json?facets[city][]=Amsterdam&facets[price][]=free-121
|
|
|
|
|
|
The documentation of the API for pushing events, or pulling, individual events is much the same as it was (for now - it may still change in the next 4 weeks).
|
|
|
|
|
|
> My idea is to install a calDav server (like Baikal or Radicale), a
|
|
|
> calDav web client (https://www.inf-it.com/infcloud/ or agendav.org), and
|
|
|
> a daemon to import periodically the activities from whatever form they
|
|
|
> come to a calendar format. This would map radar events to calendar
|
|
|
> events and potentially radar groups to cardDAV contacts.
|
|
|
|
|
|
Your welcome to. There is also iCal output for the groups themselves:
|
|
|
|
|
|
https://radar.squat.net/ical/node/41
|
|
|
|
|
|
For Group ID 41 (which you'll notice is the same ID used above, so while the links are missing you can get the ID from the API).
|
|
|
|
|
|
iCal is good as it's a standard, but it's pretty limited, and frequently badly implemented (even ours has issues open for it).
|
|
|
Language seems rarely supported, categories are basic in the extreme, the time of the event is often in UTC so has to be correct to be displayed in local time (which is often not declared in the feed) and more important for the type of events we're handling:
|
|
|
|
|
|
I've not worked out a way to differentiate between the
|
|
|
'Organizing group' (the entity that is organising this and other events - in Radar there can be multiple groups organising an event) and the
|
|
|
'Physical location' (the co-ordinates, or address, where that particular event is occurring).
|
|
|
I'm sure there is a way it could be bent to our will, if you can think of I'd be interested.
|
|
|
|
|
|
Another is price. I've been working towards sharing this with an X-RDR-PRICE custom field.
|
|
|
|
|
|
-=-=-=-
|
|
|
|
|
|
One last API option, you can just use the front end! It's marked up in RDFa with schema.org events and groups:-
|
|
|
|
|
|
(using Google's testing tool as it's the only good one I know):
|
|
|
https://search.google.com/structured-data/testing-tool#url=https%3A%2F%2Fradar.squat.net
|
|
|
https://search.google.com/structured-data/testing-tool#url=https%3A%2F%2Fradar.squat.net%2Fen%2Famsterdam%2Flag
|
|
|
|
|
|
-=-=-=-
|
|
|
|
|
|
Hope this gets you started, do keep in contact. As I say I'm working on the API 1.1 in the following weeks, including for a groups site, push-and-pull into Radar, so if you have more questions or ideas fire them in this direction! |
|
|
\ No newline at end of file |