User not logged in - login - register
Home Calendar Books School Tool Photo Gallery Message Boards Users Statistics Advertise Site Info
go to bottom | |
 Message Boards » » API matchmaker ... looking for ideas... Page [1]  
robster
All American
3545 Posts
user info
edit post

Ok, so I have a new service I am looking to put out based on some work I did recently.

I need to offer an event management suite as part of my total solution, and I am looking for a good api that would help me do the following:

- Allow multiple customers to add events to my database, which could be all day, reoccuring, or one-time.

- Own all of my customers data, and not upload it to any 3rd party as part of the process of using the calendar.

- Show the events as a monthly, weekly, or daily view

Has anyone ever used googles calendar api, and does it fit these requirements ...
Has anyone used another calendar "viewing" api that they would recommend.

11/24/2009 4:38:09 PM

Golovko
All American
27023 Posts
user info
edit post

Why not write your own api that accepts your parameters (event name, dates, etc etc) this sounds super simple to do...the user can use it in whatever front end they want.

11/24/2009 4:44:16 PM

robster
All American
3545 Posts
user info
edit post

Yeah, my thought is to keep the backend of their data open via an API ... but to give them a default front end, such as google calendar, which would interact with my API, and they could embed it into their organizations websites as well.

11/24/2009 4:53:41 PM

Golovko
All American
27023 Posts
user info
edit post

by 'back end of their data' you mean their data in your database?

What I'm saying you could do is provide a url like http://www.yourdomain.com/api/addevent

and that url would accept parameters such as 'event name, start/end dates' etc...

so your URL would look like
http://www.yourdomain.com/api/addevent?name=Birthday&startDate=10-10-2009&endDate=10-10-2009

or depending on how you setup your urls it might look like

http://www.yourdomain.com/api/addevent/Birthday/10-10-2009/10-10-2009

and then your back end would parse this data and add it to the database. this allows the user to create their own front end and the ajax request or form action would be your url. You could also as you said create a default stand alone front end that they can embed on their site.

11/24/2009 4:59:05 PM

robster
All American
3545 Posts
user info
edit post

Ahh ... I see ...

Well, the users/customers would never be creating their own front ends, most likely.

The point of the solution would be to give them something they could use, like they would use google calendar ... but instead of google calendar owning the data, I would own the data, and would be able to integrate it into the rest of the solution that I am providing.

Its going to be a bit of an event management/marketing/publishing system, with several different front ends, such as on their own website, on facebook, on the iphone ... integrated with location/mapping information.

11/24/2009 5:04:03 PM

Golovko
All American
27023 Posts
user info
edit post

got it...it sounded at first that you wanted them to have the option to create their own front end. So just like something like Twitter provides an API so you can build your own twitter client.

but you more or less want to provide them with the front end client and the back end. I would call it a 'widget'

[Edited on November 24, 2009 at 5:06 PM. Reason : asdf]

11/24/2009 5:05:47 PM

robster
All American
3545 Posts
user info
edit post

Exactly ... and since I dont want to spend the gobbs of time it takes to create a slick calendaring front end, I want to be able to use someone else's calendar API as the frontend for my widget.

11/24/2009 5:10:10 PM

 Message Boards » Tech Talk » API matchmaker ... looking for ideas... Page [1]  
go to top | |
Admin Options : move topic | lock topic

© 2024 by The Wolf Web - All Rights Reserved.
The material located at this site is not endorsed, sponsored or provided by or on behalf of North Carolina State University.
Powered by CrazyWeb v2.39 - our disclaimer.