Quick question regarding submitting both form data and json data to a Symonfy endpoint.
I have FosRest bundle and a form with a PercentType
The PercentType transforms .95 to 95 for the view purposes, which means when submitting via a form 95 is expected. However my API sends and receives data in the model format ie 0.95.
Now when a user POST's json to the api 0.95 is transformed by the form to 0.0095 (dividing by 100).
I want to use the form in both cases to map, transform and validate data.
My first guess was to change the PercentType to NumberType depending on the request format (json vs html). Alternatively disable the transformer.
Has anyone got any experience with this situation? It's the same issue for MoneyType when storing values as cents.
Related
I trained a Custom Form Recognizer Model. It tests great. But I can't find the API endpoint to call that returns ONLY the key/value pairs for the form I sent the model to analyze.
Example:
I trained a custom model to find First name and Last name only
When I POST a PDF to the endpoint:
https://{my-project}.cognitiveservices.azure.com/formrecognizer/documentModels/{my-model}:analyze?api-version=2022-08-31
Then view JSON from the Operation-Location header:
https://form-rec-ocr-test.cognitiveservices.azure.com/formrecognizer/documentModels/{model-name}/analyzeResults/{GUID}?api-version=2022-08-31
I get aaaaallll the text on the submitted PDF instead of only the First name and Last name fields. I just want the key/value pairs to insert them into a table.
What is the correct API endpoint to call? The API docs here are focused on pre-build models instead of Custom Models.
For some reason, this was not lined out in any documentation I came across. Found the answer in this video #36:30.
The data was in the original JSON object, just at line 3300 under the document node.
Would simplify things if the Form Recognizer API could return ONLY the document array by defining a simple query parameter.
I want to render a UI from a jSON string that has multiple layers.
The user should be able to enter data, which will then be stored and shared, without the overhead of the jSON Render Structure.
However, the assignment of the data must be possible.
The app renders a template from a multidimensional json string that can capture metrics (user inputs). The measured data are entered via text fields by the user.
There are different windows in the app, which are rendered from different json UI-render-files.
The stored algorithms in the windows at the Frontend differ.
The following should be possible:
All windows are created with different jSON strings (works with build_value now).
The user's input is saved. (Currently only works by saving the render json string with the data under a different name (with Package: Shared Preferences)).
The data entered by the user is copied from one window to the other window. (Data Binding / Data Mapping)
The data entered by the user will be sent to a backend.
I only have the idea to use id's in the render json, which allow a mapping.
Are there better solutions?
Saving the entered data is possible by saving the whole jSON - String with an other name.
The goal is to map the data.
It should also be possible for the user to insert another object for the measurement data acquisition at the client / device. The entered data must also be saved.
This sounds like a REST API. Then you would use a frontend framework like angular or react to take user input.
I could build this with a .net core web api with sql db as the backend. this would be a web service (REST API solution) on the backend of your solution.
Next I would integrate Swagger with dependency injection and add authentication.
now its time to create the front end that will use your tested Web Service.
you would have 1 side of your SPA POST new JSON to the Web service in a form.
you would have the other side GET the new record as a new tab with pagination or in a table with pagination.
This would be a good PoC for your idea and will let you learn the parts of the solutions architecture in your language of choice. the "design" would be the same no matter what language your choice.
backend web service can be done in a flask and with a MySQL DB. or with any other combo you have skills with.
the Frontend could be done in knockout.js, making it a little easier to learn than angular or react.
Please create new questions when you choose your software design. I would love to give answers for each:)
I would love to level up with you! ;)
We want to send some events to Application Insights with data showing which features a user owns, and are available for the session. These are variable, and the list of items will probably grow/change as we continue deploying updates. Currently we do this by building a list of properties dynamically at start-up, with values of Available/True.
Since AI fromats each event data as JSON, we thought it would be interesting to send through custom data as JSON so it can be processed in a similar fashion. Having tried to send data as JSON though, we bumped into an issue where AI seems to send through escape characters in the strings:
Eg. if we send a property through with JSON like:
{"Property":[{"Value1"},..]}
It gets saved in AI as:
{\"Property\":[{\"Value1\"},..]} ).
Has anyone successfully sent custom JSON to AI, or is the platform specifically trying to safeguard against such usage? In our case, where we parse the data out in Power BI, it would simplify and speed up a lot some queries by being able to send a JSON array.
AI treats custom properties as strings, you'd have to stringify any json you want to send (and keep it under the length limit for custom property sizes), and then re-parse it on the other side.
I have a situation where I have to write a api to create a resource and amongst datafields that I need to accept is a string that is basically contents of a html file. As I see it I have a choice between structuring the entire thing as a json object where this field is a string field with urlencoded html string , and having the Content Type as multipart/form-data where each of the fields and the html string (UTF-8 encoded) is a part in the message.
Not using json is something I am not comfortable with as I feel violating the REST standards in not structuring the content of the entity I am about to create thus there is a loss of information for the consumers as they can't tell immediately looking at my api definition about what data to feed to it. But practically multipart/form-data handles stuff like html file content better and more efficient as I will not have to urlencode it and can control the char-encoding also.
What will be a better approach in current context and upholding RESTful principles ? Also are there other trade-offs i should be aware of ? what about parsing a json with a huge string field (~ 200 Kb)embedded?
EDIT :- I was reading some similar questions on SO and one approach that stood out was the 2-step approach of making a first call with metadata to create the entity and then upload the file as an UPDATE process to the created entity wherein we use multipart/form-data. In that context, I guess , what I am asking is how sound is an approach where I send both metadata and the file in a single api call as multipart data , where each metadata field is actually a part in the multipart message as is the file.
The canonical way to upload files to REST API is using the multipart/form-data. As W3 recommendation guide says:
The content type "multipart/form-data" should be used for submitting
forms that contain files, non-ASCII data, and binary data.
Multipart/form-data has advantages over base64 to represent binary data. Is sticked to REST/Http philosophy, and simplify the develop of API clients.
Returning values from Forms: multipart/form-data
W3 Recommendation guide
The good practice is to use multipart/form-data whenever files are uploaded to the server along with database fields. Do not send a base64 JSON string as the request to your Rest API as it might corrupt the file or degrade the performance of your application.
As far as documenting multipart/form-data Rest API for your consumers is concerned you have to force your API consumers to use the same form fields which you have predefined in your web service.
Returning Values from Forms: multipart/form-data
I started using FormData objects everywhere on the client-side, in lieu of regular form input fields, for dynamic REST posts. FormData is presented in a positive light in various tutorials, so I went with it.
However, down the line, this caused me problems when decoding the form data into my Go structs. FormData objects are sent as "multipart/form-data" (regardless of files being sent) and I believe my decoder in Go didn't convert the raw data back to string form. Eventually my SQL queries were throwing panics, as hex data was being sent in where strings should have been.
So with some adjustment, I could use FormData however I've decided to revert to the simple universal recommendation: Use "multipart/form-data" only for special cases like when sending files. Otherwise, just use regular "application/x-www-form-urlencoded".
We are currently trying to set up routes in such a way that the returned content-type can be set using a route parameter. The routing is all working properly now, but there is one problem. If one requests html, then the normal view script is rendered. The data we provide to this script can be anything from a string to a collection of objects, and the view script decides what to show to the user.
If however JSON response is requested, then we just provide the data returned from our controller as JSON. However, some data should not be made publicly available to the user, and hence some filtering is required. Is there any possibility to use JSON view scripts (as in ZF1 with context-switch) in order to support such filtering? Or maybe another method?
There is no such thing as a JSON script which lets you decide what to render and what not. You have to provide the proper data in the view model such that only the data is given that is eligible to be displayed.
I have been thinking about a hook in the JSON renderer so you can filter the view model's data based on the context of the request, but such thing does not exist yet. Unfortunately, you have to select the data in your controller or model.