All

Another question for those who may have trodden this path before. I am progressing well with the combination of EWB talking to EWS talking to EDB. However, it seems likely that I will need to utilise the module capabilities of EWS rather than the built-in dataset handling. This is because other (non-EWB) clients may need to hot my datasource and I therefore need to present more of a REST API. Does this make sense?

Assuming it does, then I'll likely want to utilise cookies for authentication, passing some form of secure token to the browser on successful login and then simply allowing the browser to automatically pass this back to me as part of each subsequent "REST API call". Anybody got any tips to get this working?

Finally, am I right in saying that EWS has yet to support HTTPS? If so, may I ask Tim if there is a timeline for this functionality?

Thanks
Mark

Reading this back, I think I can summarise by asking more directly:

Has anybody used an EDB back-end with an EWS front-end and custom modules to create a solution that talks to EWB (and other clients) over HTTPS via a REST API.

Thanks
Mark

Mark,

<< Has anybody used an EDB back-end with an EWS front-end and custom modules to create a solution that talks to EWB (and other clients) over HTTPS via a REST API. >>

For now, if you want to use the EWB Web Server that we provide, you'll need to use Stunnel, available from stunnel.org, for any HTTPS access.

As for REST, if you decide to go that route (full-blown REST), then you'll need to write an EWB Web Server module that handles all of the path handling for the parameters, etc. and translates them into something that the TEWBDatabaseAdapter/DataSetAdapter components can handle.  Frankly, you're looking at essentially re-doing everything that is automatically done for you right now. The problem is that the EWB dataset handling isn't really architected around using REST-ful calls, and only uses GET/POST with parameters.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks all. One last question, because maybe I'm over-thinking this......

My scenario requires a solid, scalable datasource at the back-end. Likely max 100 concurrent users, max 50 inter-related tables. I'm thinking Elevate DB in CS mode.

I thought EWS for the web server just because my own client apps will all be written in EWB. I guess it's ok with 100 users? Tim has already explained how I can introduce HTTPS as required.

My area of confusion lies around a "REST API" vs the native EWS handling of data requests. As an example, I may wish to add a record to a table via a POST, which I know that EWS supports. However, this action might also need to add something to another table "behind the scenes" for example to create a log entry or similar. I would want this to happen server side without the logic in the client. That's why I had thought REST API. Is there a way that I could handle this via EWS, maybe using modules? Isn't that a pseudo REST API anyway?

Sorry, but once I get my head around this I'll be off and running

Mark

Thanks all. One last question, because maybe I'm over-thinking this......

My scenario requires a solid, scalable datasource at the back-end. Likely max 100 concurrent users, max 50 inter-related tables. I'm thinking Elevate DB in CS mode.

I thought EWS for the web server just because my own client apps will all be written in EWB. I guess it's ok with 100 users? Tim has already explained how I can introduce HTTPS as required.

My area of confusion lies around a "REST API" vs the native EWS handling of data requests. As an example, I may wish to add a record to a table via a POST, which I know that EWS supports. However, this action might also need to add something to another table "behind the scenes" for example to create a log entry or similar. I would want this to happen server side without the logic in the client. That's why I had thought REST API. Is there a way that I could handle this via EWS, maybe using modules? Isn't that a pseudo REST API anyway?

Sorry, but once I get my head around this I'll be off and running

Mark

Mark Brooks wrote:

> Thanks all. One last question, because maybe I'm over-thinking
> this......


Getting a good understanding of what can and cannot be done is
important. Also, how important REST or REST-ish or no REST but
something good enough is for you. I was a big user of the RemObjects
SDK, so didn't look at the EWB server at all, but it is quite capable
and extendable, but isn't pure REST. Indeed, most people don't actually
want pure REST (which is stateless, so you have to pass authentication
with every call), but want REST-ish which can use a cookie and keep
state for example.

Basically, I think it either comes down to starting off with a
different server technology and using that (with or without the JSON
data format for compatibliity), or using EWB's server and extending
that.

Also, one last thought - 100 users needs to be defined better. What are
they doing, and how often? Is that 100 updates per second, or 100 reads
per hour, or what?


--

Matthew Jones

+1 for what Matthew wrote.

My 2 cents - REST is rarely worth the effort unless you specifically need it. You'd know for sure if you did. I have great success with using "rest-ish" and clean-ish URLs (for example "https://domain.com/clients" to get a list of clients) into either a PHP (FatFreeFramework) backend or a B4J server. Both make routing really easy. I pass ALL parameters via POST. It's not really REST I know, but it works for me and it makes it easy to change back end technologies as long as they allow scripting.

I can't tell from skimming over the docs whether you can do extra curricular activities on the EW web server (eg running more scripts/DB queries beyond the initial one), but if you can't and don't want to write modules for it, then I thoroughly recommend the above. And done correctly it can scale to as many simultaneous users as you need.

squiffy wrote:

> unless you specifically need it. You'd know for sure if you did

The main reason for true REST is scalability, where any call may be
routed to a different server. But there are other scaling solutions,
and many people call their systems REST which aren't really fully
RESTful.

There is a nice course on PluralSight on designing a WEB API, and it is
quite pragmatic.

--

Matthew Jones

I developed this platform for the my company

https://www.mbspay.it

i have use EWB + php (for the server side) and MySql database

For entry digit for username test and for password test

for the cookie and for the operation db i have operation only php for security .

the date the client passed all POST to SERVER , i have developed the file dataset.php for the operation with db and i have created one file php for form . I have created the file controllosessione.php for the control the sessiond valid .....etc.....

Pasquale:

Very nice.  I love the animation in the "menu" - are those panels with images on them...

Walter