I am working for a business that deals with auto body shops - we have them subscribed to a service and want to enhance that service by utilizing the Goolge Places API.
I would like to update the places entries by adding or changing specific photos, descriptions and contact info. I realize there is a section of the documentation that deals with adding a 'place report' but I felt this flow was unclear and/or ambiguous.
In other words, what happens when i place this report? Is there a vetting process that only google is involved in? Does this even do what I'm asking it to do? Is this creating a new entry entirely?
Any help on clarification is appreciated. I may have missed the obvious here so if you feel that way let me know with a link please.
The Places Photo service is a read-only API that allows you to easily add high quality photographic content to your application.
https://developers.google.com/places/documentation/photos
Did you not understand the 'read-only' part?
Related
We have a currently a large API which serves many different clients and apps. As we want to move forward, we are in discussion to split up our API endpoint into dedicated ones.
Our base-URL is like this api.domain.com/{apiVersion}
With this, we serve for example our main App and an Reseller App:
Users Endpoint: api.domain.com/v1/users
Resellers Endpoint: api.domain.com/v1/resellers/sales
Our Idea is to change that either into:
api.domain.com/users
api.domain.com/resellers/sales
or into:
users.domain.com
resellers.domain.com/sales
I didn't find any good best practices on that, so maybe some has an interesting link or some opinion on that matter.
My preference would be api.domain.com/..., as everything is an API and you dont have to change the base url, but the second one makes it more dedicated imho.
Thanks in advance.
It might be useful to review Roy Fielding on Versioning, Hypermedia, and REST.
Unfortunately, versioning interface names only manages change for the API owner’s sake. That is a myopic view of interface design: one where the owner’s desire for control ignores the customer’s need for continuity.
....
It is always possible for some unexpected reason to come along that requires a completely different API, especially when the semantics of the interface change or security issues require the abandonment of previously deployed software. My point was that there is no need to anticipate such world-breaking changes with a version ID. We have the hostname for that. What you are creating is not a new version of the API, but a new system with a new brand.
(emphasis added)
You can also review Fielding's slides from Evolve '13
I want to get all of my users to see announcements. As you already know, we can't force everyone to use a dashboard that would have the announcements located in it as outlined here: https://www.powerobjects.com/blog/2011/11/22/adding-announcements-to-the-dashboard-in-crm-2011/. I could add this component to the most frequently-used dashboards, but I'm not going to get complete compliance. Too many people use user-defined dashboards and views. Further, not all of our users use email or other correspondence consistently, so my channels of communication for updates to the system are limited. My best bet was to create a popup upon login containing announcements, akin to the "pending email" warning, which would appear upon login regardless of any other conditions:
I've dug around to try and see where that warning comes from, in hopes of reverse engineering it to build a new component... but I just couldn't figure it out. I've seen options on how to disable or circumvent it, which naturally is the opposite of what I'm trying to do.
Is something like this possible?
Unfortunately this is a missing most wanted piece/feature even today in latest 365 versions.
We are using Web resources in global dashboards to socialize such thing, as announcements are deprecated. We cannot circumvent personal dashboards as default scenario.
We are planning to explore Learning path for this requirement, but that’s not applicable for your version.
Is it possible to create contact folders with Outlook REST API? I've looked into the docs for Outlook Contacts API and found only references to fetching existing contact folders (even in the beta version).
Other questions seem to focus on using C# and probably some specific SDK for that. I'm using Python, so that wouldn't work for me. I haven't found, both on StackOverflow and through Google in general, any definitive answers to this question. From the lack of any mentions in the docs, I'd assume it's not possible, but just wanted to get a definitive and/or official answer on that matter, if possible. Also please let me know if I missed something during my research.
Thanks!
There is a create folder operation, although it seems specific to Mail folders and doesn't take any parameters that can specify a folder type. It's possible it may take on the same item type as the parent folder, but I'm not certain.
Otherwise there is a create method specific for Contact folders in the Graph API; see https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/contactfolder_post_childfolders.
If you want a Python specific SDK, see: https://github.com/microsoftgraph/msgraph-sdk-python. Code samples: https://github.com/search?q=python+sample+user:microsoftgraph&type=Repositories
FYI, you can use any code platform to work with the Office 365 or Graph APIs, as long as they support REST.
After reading #Eric Legault's answer it gave me an insight to try something blindly. Even though the docs do not state it, you can create a folder by doing a POST to the contact folders endpoint with DisplayName property in the body.
So do
POST https://outlook.office.com/api/<version>/me/contactfolders with {"DisplayName": "folder_name"} in the request's body and it will work, returning the usual 201 Created response code.
This worked for me in both v2.0 and beta endpoints.
As of this writing, Outlook Contacts' UI (self-entitled Outlook People) is terrible and not user-friendly at all (either that or I just suck at understanding it), so I actually don't know how to create or delete contact folders through it, but I'm glad the REST API does the job :)
I am building an app where two different users will edit the same document online, using only plain text. For this I am using the google-api-php-client-master hosted on github.
There are some examples, but I don't understand what I need to do to achieve my goal. The official documentation is deprecated because it reffers to a library that is not online, and all the classes have different names and ways of working.
I already got my credentials, and know how to get a list of the documents hosted on my drive account. But now I need to:
Create new document
Grant access to a non-google logged in user, just accessing the link
I don't expect anybody to give me a written solution, but to know where I have to start.
Thanks a lot for reading.
Ok im trying to do almost the same thing and this is what i know so far:
Most importantly please reffer to the docomentation: https://developers.google.com/drive/v2/reference
There is a written example on how to create new file!( section files->insert)
One way to make a gdrive file public is to share it to the web via the google api. Another way is to make revision of it( section revision->update) and then publish it( by setting "published" = true in the update request).
Being aware of your requirements i gues that the publishing wont really help you achieving your goal, because it is just a revision of the document from the past and not its current state.
I have built a little Web UI for Pidgin(respectively all libpurple based messengers) together with DBus and Sinatra.
It was for fun and learning purposes and now I'm looking for ideas to extend it.
Can you think of any useful applications or extensions for it?
Since I work on this project to learn something new, ideas for other technologies to be used/combined are welcome.
Finally here is the link: pidgin-web-ui
I few things that that might use to many many people would be:
good and simple to configure https support, so that users in "monitored" countries to be able to still chat freely (if the server is somewhere else).
Unified Message Archive . Many IM clients have various archive functions, but are different, limited, hard to search, and many are "client only", so not accessible when one needs them the most. Since Pidgin can connect to so many IM networks, it would be cool to have such a "global message hub archive". This would ensure that everything the user is talking is archived (very useful for businesses too), easy to search, available on a server (so always at hand).
File Archive on the server. The same as the Unified Message Archive, but for the files/images users exchange. Having them on the server (with a hash for easy sync) as a backup and archive would greatly reduce the traffic if they need to be shared more than once.
The would be many more nice features, that would help many users, but the above 3 seem to miss from usual IM software.
My idea after a brainstorming minute:
Dropbot
Create a messaging account anywhere and add this account as a contact to your messenger. This contact is your Dropbot.
Change your interpreter UI so it does not display a conversation but a log. In this way you can just drop things to the contact like interesting links. There could be a Dropbot for a read later queue, your favorite citations or for a list of funny findings.
You could then extend your UI to a little mashup. It could follow the links and grap the title of the page and a content preview just as Facebook does it when posting a link to your wall.
You could further extend your app by adding post-drop behavior to the Dropbot.
Dropbot could post your link (probably with a message) on Twitter or Facebook.
Dropbot could automatically distribute the link to the other contacts of it (like your friends)
Ok, that sounds fine... but you could do that without a message bot inbetween. What's the deal?
For me the advantage would be that my IM is always open and it would be fairly easy to drop a link. You could do the link dropping with Delicious or post stuff to a Google Wave, yeah. But I don't like to go to a web page, log in and organize stuff in the UI. Actually I stumble upon those links when I should do more important stuff instead. So just dropping it to my IM Dropbot contact would be cool.
Why not extend it to cover all the basic features of instant messaging (sending/receiving messages, adding contacts, etc...)? Seeing how many features you can reproduce may be a fun exercise. Create your own little Meebo...
Want to have fun?
Make a Markov-chained-based chatbot integrated into the web app. Make it use scraped web search results for the content, after searching for terms parsed out of the human's responses. That should be fun, and will give you funny, and sometimes eerily smart-looking results. Have fun!
I have seen your code. Why not split dbus_thread into a event_machine daemon for further scalability?
Integrate it with Twitter. Trace conversations (#Replies), including multi-party involvement. Log them. And so on.
Many interesting features and a popular, original API to learn.