How to manually create JSON object for GMail API ('Message' object) - gmail-api

I'm trying to create a system for creating and sending emails through the GMail API. I have gotten a receive workflow working (Oauth, retrieves and parses emails). So I have seen the 'Message' JSON objects that Google uses.
Now I want to send out a 'Message' that was created by my system. So I'm looking for information about what is the minimal or basic set of elements needed to create a valid 'Message' object for Google's GMail API.
My platform is using FileMaker Pro... so I can't really use any existing library for their templates and functions. I am looking to build the JSON object directly, with text functions.
I have seen the GMail API documentation. It doesn't really seem to clarify what is required or optional. One side point: Message ID - it doesn't describe the parameters for that. Can I set it to anything I want? Is that something only generated as a PK for Google's own database to store it under? (Apparently it's not required, as it seems it will be defined and returned in the Send response.)
I note that it has the 'Raw' element... maybe it's simpler to build the RFC 2822 text from a template of some sort, doing targeted replacements? It still is a matter of - what's minimally needed in the template? (Would eventually like to be able to send attachments, too.) And it seems that building a JSON object version would be more readable, maintainable, and/or robust.
Thanks,
J

Related

cakephp 4 - model without database

In a cakephp 4 project in need to read data from a third party api.
I found this doc for cakephp 2, but no equivalent for cakephp 4.
https://book.cakephp.org/2/en/models/datasources.html
Where is it ?
Thanks
Read data from a third part api direct in your controller using HttpClient or other libs.
https://book.cakephp.org/4/en/core-libraries/httpclient.html
In CakePHP 4 the ORM is structured quite differently, data is retrieved via a Datasource, so you essentially need an HTTP-backed Datasource.
While CakePHP doesn't naively supply an HTTP source, there are a few of plugins that do, such as:
https://github.com/imsamurai/cakephp-httpsource-datasource
https://github.com/CakePHP-Copula/Copula
It looks like these may have some drawbacks and limitations - and in general be fairly advanced setups requiring some creative problem solving. So in the end, as the other poster mentioned, it may in the end be easier to just make HTTP requests directly if you don't require any of the ORM features (validation, Entity classes, virtual fields, Event hooks, etc.)
If the API communicate using POST/GET requests and responds using JSON format (which is usually the case), you can use the Request & Response Objects to ask and get data from the API

Azure AD B2C Custom Policy Localized REST API Conflict Response

This is sort of an extension of this question here. I have a policy that calls a REST API. The API returns an error message and this message needs to be localized.
One way is to of course get the API to return a localized message, but is there a way for the CustomPolicy itself to localize the error code? According to the CustomPolicy Docs, a REST API can send an error code along with the Conflict error code. Our thinking was to use this error code as a key and select a localized message (from the messageValue enum mentioned in the answer in the link).
However, we can't seem to capture/handle the error data returned by the API. The Policy seems to handle error codes by itself and we would like to know if it is possible to inject localized exception/error messages from the policy itself.
Thanks in advance!
Edit: A little more information about the setup. We have a TechnicalProfile that has a DisplayWidget and a ValidationTechnicalProfile. The DisplayWidget is used for entering & verifying the user's phone/email and the ValidationTechnicalProfile makes the final call to the RestAPI with all the user's information to register him/her. This RestAPI call output is what we want to localize.
The suggestion in the linked SO question, from what I understand, is that we integrate another DisplayClaim (that references an enum) in the DisplayWidget, and depending on the ErrorCode returned by the call, change it to display the appropriate code. However, as per my understanding, this would also require editing the API to return only 200 along with a code. This code would indicate the true nature of the result - success or a code for one of the enums to be displayed.
Our aim therefore is to check if there is a way to follow the Policy's flow (disrupt the SignUp/SignIn process) but at the same time localize the API's displayed response.
We managed to find a workaround to this, so I'm posting this here for anyone else who might be interested in this.
Our restriction for localizations was the fact that used Phrase to manage our translations and wanted the CustomPolicy specific translations all in one place. Our CD workflow was as follows:
PolicyCommit -> Build Variable Replacement through PS -> Release Variable Replacement and localized strings replacement through PS & Policy Uploads
Barring the policy from localizing the APIs response, we had the following options to achieve this:
Sending the language to the API and having the API return the appropriate error message
in the appropriate language. We were reluctant to follow this because of a multitude of reasons, but mostly because we would also have to handle different regions, etc. in the API - something the policy does by itself.
We actually had only one API that we called, and also only two error messages that were used. Hence we created an enum with the two error messages that would be localized. We then used a chain of InputClaimsTransformations that did the following:
Repeat Steps 1 through 3 for all the errors
1. CreateStringClaim (Create ClaimTypes for each of the error codes, holding the index of the error code in the enum)
2. GetMappedValueFromLocalizedCollection (Make the localized enum choose and hold the value of the required error code)
3. AddItemToStringCollection (Add the localized error from the enum to a StringCollection)
4. GenerateJson (Add the error codes StringCollection to the JSON payload to be sent to the API)
This way, the policy performed the localization for all the errors and we sent them along with the request to the API. The API, when an error occurred, picked one of the error messages from the policy and sent it back. This method was for us, because of our CD structure and Phrase integration, much easier than actually having the translations in a file hosted on the cloud to be accessed by the API.
Hope this helps someone; I can also add code in case someone needs it :)

APEX Rest API - Swagger

I am a bit new to the whole APEX service plugins but I was wondering if Salesforce has native support for Swagger, or any similar REST description language, for the REST api's that I create in the APEX service platform?
For example:
#RestResource(urlMapping='/v1/users/*')
global with sharing class UserRestService {
...
#HttpGet
global static List<Member__c> doGet(....)
{
...
}
}
I would like the ability to return the swagger json, a WADL document, or something for this REST service (and all other REST services I have in there). Does anyone know of a way I can do this?
Thanks in advance!
There is no built in support at this time. I was interested in seeing what could be done via currently available public APIs. The first thing I ran into is the grammar does not seem to like parameters to HttpGet methods. That right there will make it challenging since the only way to get input parameters appears to be via the Request entity which means you would have to parse the actual code. In other words, there does not appear to be declarative input binding.
Further, in looking at the tooling API which let's me get some amount of "reflective" information about the class, there is not always sufficient information to render a response payload (in your case, it just shows LIST but not what's in the list)
Again, it looks like one would have to rely on a parser (there is at least one Antl grammar floating around).
(this is getting some internal attention but I can't say any more at this time)

Best practices for model validation using a REST API and a javascript front-end such as Angular

I'm transitioning towards more responsive front-end web apps and I have a question about model validation. Here's the set-up: the server has a standard REST API for inserting, updating, retrieving, etc. This could be written in Node or Java Spring, it doesn't matter. The front-end is written with something like Angular (or similar).
What I need is to figure out where to put the validation code. Here's the requirements:
All validation code should be written in one place only. Not both client and server. this implies that it should reside on the server, inside the REST API when persisting.
The front-end should be capable of understanding validation errors from the server and associating them to the particular field that caused the error. So if the field "username" is mandatory, the client can place an error next to that field saying "Username is mandatory".
It should be possible to validate correct variable types. So if we were expecting a number or a date and got a string instead, the error would be something like "'Yo' is not a correct date."
The error messages should be localized to the user's language.
Can anyone help me out? I need something simple and robust.
Thanks
When validating your input and it fails you can return a response in appropriate format (guessing you use JSON) to contain the error messages along with a proper HTTP error code.
Just working on a project with a Symfony backend, using FOSRestBundle to provide proper REST API. Using the form component of Symfony whenever there's a problem with the input a well structured JSON response is generated with error messages mapped to the fields or the top level if for example there's unexpected input.
After much research I found a solution using the Meteor.js platform. Since it's a pure javascript solution running on both the server and the client, you can define scripts once and have them run on both the client and the server.
From the official Meteor documentation:
Files outside the client, server and tests subdirectories are loaded on both the client and the server! That's the place for model definitions and other functions.
Wow. Defining models and validation scripts only once is pretty darn cool if you ask me. Also, there's no need to map between JSON and whatever server-side technology. Plus, no ORM mapping to get it in the DB. Nice!
Again, from the docs:
In Meteor, the client and server share the same database API. The same exact application code — like validators and computed properties — can often run in both places. But while code running on the server has direct access to the database, code running on the client does not. This distinction is the basis for Meteor's data security model.
Sounds good to me. Here's the last little gem:
Input validation: Meteor allows your methods and publish functions to take arguments of any JSON type. (In fact, Meteor's wire protocol supports EJSON, an extension of JSON which also supports other common types like dates and binary buffers.) JavaScript's dynamic typing means you don't need to declare precise types of every variable in your app, but it's usually helpful to ensure that the arguments that clients are passing to your methods and publish functions are of the type that you expect.
Anyway, sounds like I've found the a solution to the problem. If anyone else knows of a way to define validation once and have it run on both client and server please post an answer below, I'd love to hear it.
Thanks all.
To be strict, your last gate keeper of validation for any CRUD operations is of course on server-side. I do not know what is your concern that you should handle your validation on one end only(either server or client), but usually doing on both sides is better for both user experience and performance.
Say your username field is a mandatory field. This field can be easily handled in front-end side; before a user click submit and then been sent to the server and then get returned and shows the error code. You can save that round trip with a one liner code in front-end.
Of course, one may argue that from client-side the bad guys may manipulate the data and thus bypassing the front-end validation. That goes to my first point - your final gate keeper in validation should be on your server-side. That's why, data integrity is still the server's job. Make sure whatever that goes into your database is clean, dry and valid.
To answer you question, (biased opinion though) AngularJS is still a pretty awesome framework to let you do front-end validation, as well as providing a good way to do server-side error handling.

Twilio TwiML XML String instead of url

I want to call the twilio voice API without providing the URL.
Normally you would do it like this using python:
call = client.calls.create(url="http://demo.twilio.com/docs/voice.xml",
to=request.receiver,
from_=sender_number)
Instead of providing the URL I want to provide the XML-String. Is that somehow possible?
Background:
I'm generating the XML via a google cloud endpoints api. The response is in JSON format and a variable contains the XML. I need to parse the JSON to get the XML.
Sounds like you could use the echo Twimlet.
https://www.twilio.com/labs/twimlets/echo
Echo will just output whatever TwiML is passed into it via the URL. It is useful for building stateless, outbound apps, where arbitrarily complex content of the call is pre-generated and just passed into the REST API to initiate a call.
Example: http://twimlets.com/echo?Twiml=%3CResponse%3E%3CSay%3EHi+there.%3C%2FSay%3E%3C%2FResponse%3E
Twilio Evangelist here. I'm afraid you cannot do this, however there are a number of solutions. If your call doesn't require any dynamic XML, you can host it on S3, or a similar service (I use Dropbox public links quite a lot).
If you do need dynamic XML, then we have a whole bunch of tutorials that can help you get setup with a simple web application.
Hope this helps!

Resources