问题
The restrictions of a https callbackUrl and the nature of the subscriptions as a whole makes it seem like this is something that can only be done with a publicly accessible url.
So far I have come across two potential solutions to make local development / debugging easier.
The first is the Subscription Proxy service offered by google. This workaround essentially lets you remove the SSL restriction and proxy subscription callbacks to a custom URL.
The second and most helpful way I have found to do development locally is to capture a subscription callback request (say from a server that is publicly accessible) into a log and then use curl to reproduce that request on your local/dev machine using something like:
curl -H "Content-type: application/json" -X POST \
-d '{"json for":"the notification"}' http://localhost:8080/notify
Since the requests can sometimes be large, or you might want to test multiple callback types, I also found it useful to put the JSON of the subscript request into various files (ex: timeline-respond.json) and then run
curl -H "Content-Type: application/json" \
--data @timeline-respond.json http://localhost:8080/notify
I'm curious as to what other people are doing to test their application subscriptions locally.
回答1:
The command line curl technique that you mention is the best I've found to date.
I've experimented with other solutions, such as an App Engine subscription target paired with a local script which pulls that App Engine service for new notifications to relay to localhost, but so far I haven't found one that's worth the added complexity.
Alternatively, there are many localhost proxies available. My favorite is ngrok.com.
回答2:
You might want to give localtunnel a try.
来源：https://stackoverflow.com/questions/16907280/how-to-test-mirror-api-subscriptions