I'd love to see some new functions for doing an HTTP/S POST for interacting with web services.
Amen! I have been asking FileMaker for a HTTP post functions and the ability to consume web services for about five years and they ignore me year after year, release after release. It kills me on the FM go functions that don't support plug-ins. That is where I need this H TTP post and web service consumption functionality the most. I also need the ability to handle password-protected URLs that are formed based and not URL based with basic authentication.
goes hand in hand with JSON and XML parsing
I can highly recommend Base Elements plugins... yes, I know, they are plugins, but they are FREE.
Thanks to Nick from Goya, his plugins for http POST saved me a LOT of hassle with other plugins that either did not work, or did not give any support.
+1 on this.
It would be great to be able to interact with web services.
I second the Base Elements plugin recommendation. I needed to send a POST command to a website and needed just two attempts to get the BE plugin syntax right before it worked perfectly for me.
Ann Arbor, MI
Think though this IS a thread about talking to FM people about what perhaps could and should be being discussed as native functionality. AND plug-ins dont work on Go - so that's why we need it as a core thing. Lots of things are beautiful in plugin land....
I would also love to see this feature. It would be a giant leap forward in terms of integrating FileMaker with virtually anything.
Hello, this http post functionality really needs to be native in FileMaker, server, runtimes, iwp and Go. I use plug-ins but I have been getting burned by them in the following ways:
1. They do not work in FM Go so those solutions that use plug-ins became useless in FMGo.
2. FileMaker technical support blames problems on plug-ins and will not always help me when I have fm issues and plug-ins are installed.
3. One of my favorite plug-ins for doing http posting has not been updated for several years and crashes with the new versions of FileMaker when the data returned is too large. It is not easy to predict when plug-in makers will stop supporting them and it is a pain to switch hundreds of scripts to a new plug-in that might become obsoleted on the next version.
Sometimes it seems that the FileMaker product team uses plug-ins as an excuse not to put the http post And consuming Web services functionality into the product natively and I think that is sad and prevents the entire FileMaker line from being able to integrate with almost anything.
Let's put it this way - the FileMaker platform will be a dying beast if it doesn't play the integratation card. There's too much momentum on the web/DB/NoSQL side where integration is fairly more straightforward.
Yep + 11 (in the Spinal Tap sense)
Wrong place to put this stuff I know, but while the right eyeballs on it.
Think user friendly REST API support (and all that goes with it) would be one of biggest ROIs for FM Inc. Would extend Filemaker's value as a data hub and could leverage the community to extend Filemaker in infinite directions.
It does need the kind of effort put into Custom Functions so API code can be easily transferred/shared in the community. To allow novices to leverage without needing to fully understand whats going on under the hood. (while they learn)
I know plugin devs (BaseElements, MBS, Troi URL, Scriptmaster) already doing great job with this stuff, but really needs to be native (and in FMGo).
In summary would love to see support for:
1. POST & GET (with some Auth support) + PUT, DELETE etc.
2. Some Authorisation Support eg. A wizard for OAuth 1 & 2 would cover majority of big API's eg. Google, Facebook, Stripe, Xero, Salesforce, Dropbox, Soundcloud. (and allow Copy & Paste of setups would be very useful)
couple of browser plugin example doing good job of making it easy (if little over complex in places)
https://addons.mozilla.org/en-US/firefox/addon/restclient/ Firefox REST plugin
https://chrome.google.com/webstore/detail/cokgbflfommojglbmbpenpphppikmonn Chrome REST console
3.Internal Filemaker JSON support to parse at a minimum (eg. GetObjectValue, GetArray, GetArrayCount etc). Maybe goes hand in hand with new *FM (Associative) Array type. Natively in Json (or XML that can be returned in Json)
* A standard filemaker Dict/Array/Map type would also add a lot of value (Code sharing etc). Theres lots of great methods and Custom Functions out there but 'lots' is the operative word, could do with an official standard here.
These are all great suggestions for dealing with more advanced REST APIs (most simple REST APIs stick with GET and POST). However, I'd like to reiterate that just a simple POST with no other HTTP verb support is sufficient to accomplish everything else, since we can write a custom proxy in between FileMaker and the rest of the world.
I'd love to see all of this stuff (PUT, DELETE, custom http headers, built-in OAuth support), but I don't want FMI to put off simple POST support because of an explosion of feature creep ideas.
Yes +13 for FileMaker 13 or FileMaker 12.5 which ever comes next. I love your recommendations. What do you think is the trick to getting FileMaker, Inc to put this functionality into the next release and not ignore these requests like they have on the last five released versions?
jbarnum wrote: I'd love to see all of this stuff (PUT, DELETE, custom http headers, built-in OAuth support), but I don't want FMI to put off simple POST support because of an explosion of feature creep ideas.
Agreed, quick iterative wins all the way (al la ExecuteSQL).
smower wrote: Yes +13 for FileMaker 13 or FileMaker 12.5 which ever comes next. I love your recommendations. What do you think is the trick to getting FileMaker, Inc to put this functionality into the next release
Yes +13 for FileMaker 13 or FileMaker 12.5 which ever comes next. I love your recommendations. What do you think is the trick to getting FileMaker, Inc to put this functionality into the next release
If Jesse says POST is critical, that's what we should lobby for (he's been knee deep in these APIs for years - i've dabbled with a few). The other bits aren't deal breakers but would make the API world a lot easier for the rest of us.
The oAuth stuff is probably stretching it for FM Inc, they need to know stuff isn't gonna change (and is backward compatible for at least a few years). A tough rope to walk in today's world but the upside is huge. i.e. Build integrated solutions for just about every major cloud application out there.
smower wrote: not ignore these requests like they have on the last five released versions?
not ignore these requests like they have on the last five released versions?
Can't say I agree with you here. We've got GET now and it's elegantly done. We got SQL SELECT. We got CSS under the hood and all opportunities that could bring. I think its pretty bold for a company like FM to be honest. I like what they are doing.
It's a balance between the functionality level here which enable or limit.
With Send Email we can indeed send and email, but text only and with only one attachment. Much real work requires html or multiple attachment we have to get familiar with zip functons ( or in my case PDF maniplation) or plugings that do the same.
Execute SQL as we have it now is the esame but our expectations might be for more of the keyworks to be imlemented over time.
Simple POST for sure, but headers and authentication methodologies are varied, the Amazon API I have just worked on for someone is wildly singular in its approach, so some roadmap wold also be helpful, to know, if this gets implemented, how fast and how far will future changes bring additional feature?
With v12 and the ability to get a URL directly, you can easily invoke some server-side page that takes the original request, converts to a post and gets data from a web service. Sadly, it requires a true field in order to do so - it would be nice to set directly to a variable. The fact that a dialog comes up periodically, even when "show no dialog" is set is also a pain. So as Jesse mentions use of a proxy, you can still do that with the existing GET.
But basic POST support would be great. So many web services DO require alternate http headers and auth, so it's use would still be limited.
My biggest need for POST support is to get around the length limitations on GET. The other issues, such as alternate http headers and auth, can be worked around by using a custom proxy. Length limitations, however, cannot be easily worked around.
In FileMaker 12 I used InserFromURL script in combination with a rudimental parsing.
Is not a best practices, but usefull in little contexts.
This is a FileMaker Go demo app.
I also run into the problem with get and length requirements. Also, when passing passwords to login to sites, 'http get' seems much less secure then 'http post'. I would much rather post them then send them through the url with a get command. I hope if they add http post that they would allow headers and so forth so that it would work with the web services we use without having to do extra web page workarounds.
So what was everybody's take or thoughts from the web conference today? Did it seem like they said they are aware of the request for http post however they think it is too complicated for the basic FileMaker user and thus are hesitant to add it?
That file you sent was kind enough to lock me into Kiosk mode, disable
every menu command andkeyboard shortcut, in FM 12 Advanced and not let me
get out. Probably not your intention but not the kindest thing to do. For
those who do get stuck, try putting your computer to sleep and then
awaking, on my Mac it gave me back access to the Finder where I was able to
force quit FileMaker.
I don't think that they would have mentioned it with a bullet point on the slide if they were not at least seriously thinking about adding it. So yes, I feel that it's definitely on their feature request radar which can only be a good thing!
For those who are curious, both of these solutions have really easy ways to specify headers and other params - they are also great for debugging web services.
HTTP Client - Available at Mac App Store
http://Hurl.it - Freebie
Adding POST to FMP correctly - quite an effort.
I'm apologize for the problem!
Press "Esci" button in the top right corner of layout!
This app is design for iPhone, not for desktop and yes... in Italian language.
Inviato da iPhone!
Il giorno 04/ott/2012, alle ore 20:20, SecretWeaponLabs <firstname.lastname@example.org> ha scritto:
creato da SecretWeaponLabs in FileMaker Product Management Q&A Topic Suggestions - Visualizza la discussione completaFabietto, That file you sent was kind enough to lock me into Kiosk mode, disable every menu command andkeyboard shortcut, in FM 12 Advanced and not let me get out. Probably not your intention but not the kindest thing to do. For those who do get stuck, try putting your computer to sleep and then awaking, on my Mac it gave me back access to the Finder where I was able to force quit FileMaker. Per rispondere a tale utente, rispondi a questo messaggio e-mail -o- accedi al messaggio su FileMaker Technical NetworkAvvia una nuova discussione in FileMaker Product Management Q&A Topic Suggestions per e-mail o in FileMaker Technical NetworkGestisci le tue preferenze email. FileMaker Developer Conference 2013 • San Diego, California • August 12-15 • www.filemaker.com/devcon
creato da SecretWeaponLabs in FileMaker Product Management Q&A Topic Suggestions - Visualizza la discussione completa
Per rispondere a tale utente, rispondi a questo messaggio e-mail -o- accedi al messaggio su FileMaker Technical Network
Avvia una nuova discussione in FileMaker Product Management Q&A Topic Suggestions per e-mail o in FileMaker Technical Network
Gestisci le tue preferenze email.
FileMaker Developer Conference 2013 • San Diego, California • August 12-15 • www.filemaker.com/devcon
+1 (plus native JSON parsing support). Would love to see all HTTP verbs and the ability to set HTTP headers as well.
Retrieving data ...