Andrea Magni

Hi @Claudio Villaschi, sorry for the late. There are some limitations with Indy and enumerating request headers. I am trying to improve the current support as much as possible. Follow this: https://github.com/andrea-magni/MARS/issues/95 Sincerely, Andrea

Hi @bioman, thanks for pointing out compilation broke. I just fixed it: https://github.com/andrea-magni/MARS/issues/94 About the encoding, MARS is a layer of abstraction over the transport protocol (http). You implement your method (I guess) returning a Delphi string value. MARS serializes (where needed) the values to a stream that will be used as the response of the request. Then, it's the underlying http library (MARS supports Indy, WebBroker over Apache module and IIS ISAPI and, more recently, Delphi Cross Socket framework) that sends the content to the client. Indy has this trend of setting Content-Type=text/html; charset=ISO-8859-1 as default so sometimes you get it (when using Indy/WebBroker as http layer for MARS). MARS (and Indy neither) can't easily say if your string is a UTF8 or MBCS or ANSI string, but you should know for sure. So, if you are sending an UTF8 content in your string, mark your resource/method with an Encoding attribute stating so. [GET, Path('geoconding.html'), Encoding('UTF-8')] function MyContentGenerator: string; Let me know if you solve this way! Sincerely, Andrea

Thanks, I am using a portion of mORMot (check my mORMotJWT repository: https://github.com/andrea-magni/mORMot-JWT) I have extracted (with permission) in order to benefit of their JWT implementation (that is way better than the JOSE implementation). Unfortunately, they are (were?) not supporting Linux compilation with Delphi because of ARC. That's the reason I still have JOSE and mORMotJWT support at the same time. Glad you solved! Sincerely, Andrea

Hi @NilsSchneider, would you please post here the resource definition? If I got it correctly you registered three different resource classes for the same path (systems). Sincerely, Andrea

@bioman, hi, thanks for the kind words about MARS! Would you please paste here the prototype of your method? What data type the result is? Sincerely, Andrea

We are fine thanks! Getting used to the "new normal" and looking ahead hoping things will globally improve soon. I've merged your PR a couple of minutes ago, thanks! 🙂 Andrea

Hi @Stuart Clennett, my fault! I forgot to update some prototypes here and there. Thanks for pointing this out: add these to the uses clause: , MARS.Core.URL, MARS.Core.RequestAndResponse.Interfaces change the BeforeHandleRequest assignment to : FEngine.BeforeHandleRequest := function (const AEngine: TMARSEngine; const AURL: TMARSURL; const ARequest: IMARSRequest; const AResponse: IMARSResponse; var Handled: Boolean ): Boolean begin Thanks! I'll fixit in the repo ASAP Andrea

Right, thanks @ertank! In the Source/MARS.inc file there is a specific define to state FireDAC support is included or not: https://github.com/andrea-magni/MARS/blob/edb3c7e7a43dbac2f94f124b08107a6c3f4b5074/Source/MARS.inc#L1 Sincerely, Andrea

Just in case you missed: a new version of MARS-Curiosity REST library has been released yesterday. https://github.com/andrea-magni/MARS/releases/tag/v1.4 V.1.4 adds support for Delphi 10.4 Sydney as long as many other features and functionalities to the library. I will cover most important new features with some blog posts in the following weeks. Sincerely, Andrea

Hi Marzio, TMARSResponse is intended to be used as return type of your REST methods. If you are looking for a reference to the response object (implemented by the http layer) the second writing is correct. Soon, I'll release a new MARS version and there will be an IMARSResponse interface, wrapping the underlying object (MARS will be soon able to abstract from the http layer, in order to allow use of DelphiCrossSockect along side of Indy and other libraries). Sincerely, Andrea

Glad you solved, sorry being away so much 😉

Hi, sorry for the late (!). I accepted the pull request yesterday. Will be soon available also in the master branch (I am switching to trunk based development model). Sincerely, Andrea

Hi, sorry for the late, I am trying to catch up with all messages here and on github.com. I saw the issue (81) and yesterday I made some work on the develop branch (rebasing it onto master). I attached files with your corrections to the issue, please file a pull request and I will be happy to accept it (and you will show up as a contributor as well). Thanks

I would but, unfortunately, I am lacking time and trying to spend as much time as possible adding new features (i.e. the new Devart UniDAC intregration and the Delphi-Cross-Socket support). Please ask if you need specific help. Sincerely, Andrea

@Yaron are you using the master or develop branch? I can't see hints/warnings using the develop branch. Sincerely, Andrea

Hi @Chau Chee Yang, I've never seen errors compiling this package. Which branch are you using (master or develop)? Isn't this equivalent to set -LUDesignIDE in the Compiling options? I've never been a package addicted. 😉 Sincerely, Andrea

Hi @Chau Chee Yang Fixed, thanks: https://github.com/andrea-magni/MARS/commit/c9a0d1d75a97b40a56258a6694ae6313107efd98 If you like to be mentioned in the project, feel free to open issues on Github for this kind of problems: your contribution would be public then. For the moment, I've added a comment with a link to this thread. Sincerely, Andrea

Frank Lauter suggested me to implement chunking in MARS but I haven't done it yet. I guess one should implement some sort of caching in order to avoid continuously gzipping the same content just to serve a specific chunk to the client. Would be very interesting to cover this as it may result in a great performance boost for large data transfers. Sincerely, Andrea

Hi @Bjørn Larsen, thanks for you contribution! Some thoughts: I would say compression should be done as last step before sending back the response to the client. I mean, we can take advantage of the AfterInvoke mechanism (attaching an handler or not according to Engine parameters). This should be more generally available to all MARS TMARSActivation implementation (only one in the official repository, I know). Another point is that some deployment methods (Apache/IIS) may provide compression natively and I would let this instead of our implementation. What about moving your implementation to the Server.Ignition unit (MARSTemplate demo)? See code below as draft... I guess one could even implement a symmetric BeforeInvoke to support compression also the other way around (from client to server), I don't know how this is popular/expected, however. Using Response.SetHeader may lead to multiple Content-Encoding headers to be set at the same time (TPrimitiveTypesWriter, in MARS.Core.MessageBodyWriters.pas for instance sets the Content-Encoding to provide some information about text encoding. This may be a mine misunderstanding however... I need to check this sooner or later... if anyone has something to say about this, please do!). I switched to setting the Response.ContentEncoding property as I was having trouble with Postman (and Chrome) when multiple Content-Encoding headers were set. // Compression if FEngine.Parameters.ByName('Compression.Enabled').AsBoolean then TMARSActivation.RegisterAfterInvoke( procedure (const AActivation: IMARSActivation) var LOutputStream: TBytesStream; begin if ContainsText(AActivation.Request.GetHeaderParamValue('Accept-Encoding'), 'gzip') then begin LOutputStream := TBytesStream.Create(nil); try ZipStream(AActivation.Response.ContentStream, LOutputStream, 15 + 16); AActivation.Response.ContentStream.Free; AActivation.Response.ContentStream := LOutputStream; AActivation.Response.ContentEncoding := 'gzip'; except LOutputStream.Free; raise; end; end; end ); Let me know what you think about. I would be glad to accept your PR then... Sincerely, Andrea

Hi @bioman, glad you sorted out in the meantime. The "FireDAC Basic" demo is the dataset-oriented (quite C/S+briefcase) way of handling data through MARS. I would suggest to have a look to EKON22 demo, specifically looking for the TRecord<R>.FromDataSet and the use of TMARSFireDAC there. Sincerely, Andrea

Hi @Yaron, I don't have actual numbers about the most reliable/best performance deployment method but my preferred deployment method for production is having an internal MARS REST server (Windows Service or Linux Deamon) and Apache acting as a reverse proxy (implementing SSL, caching, compression, eventually load balancing). This grants quite some granularity with respect to performance tuning and service availability (you can restart a single service or the whole thing). I also have deployed some MARS servers as Apache modules (on Linux). A couple of customers are using MARS with IIS: one is using IIRF (basically making IIS a reverse proxy and SSL implementor), keeping MARS servers standalone (not even Windows Services though this is on the roadmap). The other one is using ISAPI deployment. I have news from time to time from people using the library and there is not a clear trend among available deployment methods. Sincerely, Andrea

Hi @bioman, there are several approaches to the topic (CRUD operation against a DB). MARS doesn't dictate one specifically. Would you please specify if you are building a Delphi to Delphi solution (Delphi on the client and Delphi on the server)? You can have a dataset-oriented approach (client asks for a dataset, modifies it, changes are sent back to the server in form of delta updates) or a more general record-oriented approach (client asks for data, server sends a JSON array, client makes POST or PUT calls with modified/new data records). It also matters if you are looking for a data-centric approach (i.e. sending whole records from DB to client and back) or more interpolated approach (client commands REST server to perform operations that results in data manipulation). MARS is a lightweight library and I am trying not to dictate some aspects (more related to application than library IMO) so there are many ways to use it. Thanks for the kind words! Sincerely, Andrea

Hi, welcome to this forum and to MARS. I've worked in the past to some migration process from Datasnap to MARS (and from RemObjects to MARS too). One thing you could take advantage is that TMARSActivation class (quite the core of request / REST method execution matching) can be replaced / tweaked. This means you may change the way an http request is matched against the Delphi code to be executed to produce response. Or you may want to have a different strategy/parsing technology to fill REST method arguments from the request. Obviously this is not the easiest task in the world but may have a lot of sense especially on large projects (I've migrated large datasnap applications to MARS with minimal effort and reducing to the minimum changes in the methods code). Coming to your questions: 1) MARS can expose multiple engine (1 engine -> 1 port). Each engine can expose multiple applications. Each application can expose multiple resources. Each resource can expose multiple methods (http verbs and sub resources). You can organize resources as you like (one resource per unit, for example). I didn't get what you mean with "separate delphi project". You can deploy MARS server in several ways including ISAPI for IIS. 2) MARS serialization/deserialization mechanisms are designed to be pluggable so you can implement your own readers/writers to handle OleVariants as you prefer. 3) I have knowledge of MARS servers used in heavy load situations. Numbers are not significative because they actually depends on hardware/storage/purpose of REST methods. If you are looking for extreme performance, I would take a look to mORMot. But in 99% of my experience MARS is fast enough and REST architecture may help you to properly deal with scaling and performance boosts. Sincerely, Andrea

Hi, thanks for the kind words and sorry for the delay. I guess you are referring to QueryParam like "sort" in http://localhost:8080/rest/default/query/EMPLOYEE?sort=LAST_NAME You can use the Required attribute to let MARS check for the parameter's existence before calling the REST method. function GetDataset([QueryParam, Required] sort: string): TFDQuery; I would add a specific value in the user's token, indicating the DB to use. You'll set this value in the token at authentication time (via API key or regular login). You can see this thread for a similar approach: Keep in mind that your situation (if you store the connection name to be used inside the user's token) it's easier as you can use a connection name like 'TOKEN_CLAIM_DBCONNECTION': [Context, Connection('TOKEN_CLAIM_DBCONNECTION', True)] FD: TMARSFireDAC; And MARS will expand that connection name to the value of the DBCONNECTION name stored in the Claims of your (JWT) token. If you need some fallback mechanisms or more dynamic behavior, follow the instructions in the "FireDAC Connections" thread I linked here above. Feel free to ask whatever you need, sorry for the delay in this reply but I am abroad with family (vacation time). Sincerely, Andrea

Hi @Rafael Mattos, MARS supports JsonDataObjects but does not include them (I am thinking about changing this...). You simply need to download JsonDataObjects (https://github.com/ahausladen/JsonDataObjects) and setup your library path to compile it. Then MARS' demo should work. Let me know please. Sincerely, Andrea