#1 2021-04-04 09:55:18

JD
Member
Registered: 2015-08-20
Posts: 101

REST Design problem: a function with many parameters for GET requests

Hello there everyone,

I would like to know your opinions/experiences with designing and using a REST endpoint in mORMot that handles many parameters.

Currently my proposed function signature is like this

function TRESTMethods.Customer(Params: UTF8): RawJSON;

In order to enable customer searches by firstname, lastname, age, sex, telephone, country, dateoffirstpurchase, dateoflastpurchase etc instead of using GET, I intend to use a POST to pass a JSON document with the parameters to the server for processing. However, I've seen some say online that one can use standard GET query but with optional parameters. How is this done?

This same function will handle customer creation (using POST), modification (using PUT), deletion (using DELETE) like this:

case Ctxt.Request.Method of
     mGET:
    { code for handling GET requests} 

     mPOST:
    { code for handling POST requests} 

     mPUT:
    { code for handling PUT requests} 

     mDELETE:
    { code for handling DELETE requests} 

end;

However, I've seen some purists say that a method like this is doing too much and that it is better to break it up into smaller bits. I agree that the Customer function will be very long if I continue like this especially with the INSERT and UPDATE SQL statements needed to create and update Customer data. This is where I would like your input. How should I break up the function? Is this what Microservices architecture tries to do?

Thanks for your kind assistance,

JD

Offline

#2 2021-04-04 15:05:52

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: REST Design problem: a function with many parameters for GET requests

IF you reinvent the wheel, you would rather not use an interface based service, but a method-based service.

Anyway, I am a "purist" so for me, you should better follow DDD or KDD parterns, and define a proper application level, not expose directly your customer objects.
That is, start from the end-user use cases, not the data.

Offline

#3 2021-04-05 12:53:46

Junior/RO
Member
Registered: 2011-05-13
Posts: 207

Re: REST Design problem: a function with many parameters for GET requests

@ab we have KDD patterns examples in documentation?

I have read your presentation of KDD, just asking.

Offline

#4 2021-04-05 15:24:31

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: REST Design problem: a function with many parameters for GET requests

No real sample yet.

TL&LR: KDD is more relaxed/pragmatical - it allows e.g. to use TSQLRecord/TOrm classes in the domain instead of dedicated aggregates, and avoid defining DTOs for every application layer service.
But the core ideas of DDD - i.e. ubiquitous language modelization, domain core uncoupled from the other layers, SOLID design - are the same.

Offline

#5 2021-04-05 19:12:40

JD
Member
Registered: 2015-08-20
Posts: 101

Re: REST Design problem: a function with many parameters for GET requests

ab wrote:

IF you reinvent the wheel, you would rather not use an interface based service, but a method-based service.

Anyway, I am a "purist" so for me, you should better follow DDD or KDD parterns, and define a proper application level, not expose directly your customer objects.
That is, start from the end-user use cases, not the data.

Thanks for your reply & your suggestions ab.

However I do not understand why you think I am reinventing the wheel.

Please clarify.

Thanks a lot,

JD

Offline

#6 2021-04-05 21:44:01

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: REST Design problem: a function with many parameters for GET requests

Because there is already a REST/ORM layer in mORMot.

Offline

#7 2021-04-08 18:01:05

JD
Member
Registered: 2015-08-20
Posts: 101

Re: REST Design problem: a function with many parameters for GET requests

ab wrote:

Because there is already a REST/ORM layer in mORMot.


OK. I get it now. I had to bypass the ORM because I have a lot of legacy code (triggers, functions and procedures) in my PostgreSQL database.

Ignoring that and going full ORM is a mammoth task that cannot be undertaken at the moment. I'll have to do it very slowly to not break something in the system.

JD

Offline

#8 2021-04-09 07:35:21

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: REST Design problem: a function with many parameters for GET requests

Don't switch to ORM unless it really has a benefit.
If you have working code, don't rewrite everything.
Only for new DB/tables it may make sense.

Offline

Board footer

Powered by FluxBB