VAST and SeasideREST - Do Breakpoints delete Annotation Pragmas?

40 views
Skip to first unread message

Joachim Tuchel

unread,
Apr 22, 2021, 4:58:46 AM4/22/21
to VAST Community Forum

Dear VAST community.


I am having trouble getting my very first, simple RESTful component to work.
Let me start by telling you what I did:

  1. Created a Subclass of WARestfulHandler named CurrentTimeHandler
  2. Implemented a method called now:
    now
        <get>

        
        self requestContext respond: [:r|
            r contentType: 'text/plain'; nextPutAll: Time now printString
            ]
  3. Registered the component evaluating
    WAADmin register: CurrentTimeHander at: 'api'
  4. Navigated to http://localhost:8080/api
And got an empty page saying:

/api not found


So I started debugging around. At first I tried setting a breakpoint in my method #now, which never fired (not surprising).
Then I debugged into WAREstfulHandler>>#createRoutes and below.
I found that in WARouteBuilder class>>#createRoutesFrom:to:

the collection of Pragmas remained empty. The method CurrentTimeHandler>>#now had no pragmas. ...???????

So I removed the Breakpoint, retried, still no pragmas. So I changed the code by adding a line break, saved the method again and retried. The method had a pragma named #get.

Is that by design? Is there a reason why setting a Breakpoint removes pragmas?

So I removed the Breakpoint, resaved the method, but still got "/api not found".

Can anybody confirm that SeasideRest works on VAST? Can anybody give me a hint as to what I am doing wrong?

Thanks,

Joachim












Joachim Tuchel

unread,
Apr 22, 2021, 5:16:02 AM4/22/21
to VAST Community Forum
Okay, so here is my first learning:

The correct path for my new component / hanlder is /api/now and not api. So the method name is relevant here. Now that I know that, it is absolutely logical ;-) :facepalm:

I will now play with the Breakpoint thing again and let you know when I found out this was also a stupid thing of mine...

Joachim Tuchel

unread,
Apr 22, 2021, 5:53:03 AM4/22/21
to VAST Community Forum
Okay, forget about all of this.

I tried adding a breakpount to my #now method and this brings up /api not found, but removing it again yields the expected result.

So I mixed the fact that the same happens for two separated problems with the fact that these are still two separate problems leading to the same result. Meaning I observed /api not found for two separate reasons and made the wrong conclusions.

Joachim

Mariano Martinez Peck

unread,
Apr 22, 2021, 7:57:35 AM4/22/21
to VA Smalltalk
Hi Joachim,

Just to clarify the REST questions.. yes, Seaside REST is supported in VAST, it does work and we have customers using it. 
As to the path being 'hello' you can customize that with the <path:> pragma. Example

now
    <get>
         <path: '/currenttime'>

    
    self requestContext respond: [:r|
        r contentType: 'text/plain'; nextPutAll: Time now printString
        ]'


Should work at /currenttime

BTW, I attach a simple SeasideRESTExample app that contains a few examples with POST, queries, JSON etc. Very simple example but it may help. Check the class TestRestfulHandler. 

Best, 



--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b7c280dc-4897-4e00-9989-fb256f50fb87n%40googlegroups.com.


--

Mariano Martinez Peck

Senior Software Engineer

 mp...@instantiations.com
 @MartinezPeck
 /mariano-martinez-peck
 instantiations.com
TwitterLinkedInVAST Community ForumGitHubYouTubepub.dev
SeasideRESTExample.dat

Joachim Tuchel

unread,
Apr 23, 2021, 4:19:17 AM4/23/21
to VAST Community Forum
Hi Mariano,

thanks for your comments and sample code. I will try to answer my pending questions with it - or I'll come back here ....

One of the questions is whether one handler is meant to handle everything in its associated subpath, meaning I register one handler at, say /garage and this handler will be responsible for everything insider the /garage path. like /garage/cars/3/wheels/front-left/pressure. Do I implement all the subpath handling methods (like for /garage/cars/{id}) in this one handler and define the paths in the method pragmas? Or do I register seprate handlers for each part of the path? Or can I mix and match handlers as I please?

Joachim

Esteban Maringolo

unread,
Apr 23, 2021, 8:22:22 AM4/23/21
to va-sma...@googlegroups.com
Hi Joachim,

With Seaside REST you refine a restful RequestHandler at some path (in your case /garage), and everything that is "under" that path is handled by that handler, so you don't end up registering more handlers for each subpath.
That's how I've been doing it for years with Seaside REST.

As a side note nothing stops you from having a dispatcher (WADispatcher) registered at `garage` and then inside that dispatcher you can register other handlers (WARestfulHandler), specific for each type (e.g. `cars` and `tools`). But as far as I know you cannot mix both approaches, it is to delegate `cars` and `tools` to the registered handlers, but also have a route directly handled by `garage`. For that you'd need a WARestfulDispatcher that currently does not exist (and wouldn't be hard to implement though).

A tip (that might be redundant given your expertise) is to not implement in the handler more than the logic to validate formats, etc, and dispatch the request to the proper object. So I usually have the HTTP handler with all the routes, and then another object that deals with the actual processing of such requests.

Regards!


Esteban A. Maringolo


Joachim Tuchel

unread,
Apr 23, 2021, 9:17:13 AM4/23/21
to VAST Community Forum
Hi Esteban,


thanks a lot. This makes a lot of sense. My question doesn't arise from my wish to make things overly complicated, so the mx&match idea was not all to serious.

BUT: your comment makes me wonder if that WADispatcher thingie isn't too bad an idea for versioned APIs, where you register a Dispatcher for /v1 (and /v2 and so on, of course) and then register concrete handlers for each subpath of that api version....

At first sight, this sounds like not too bad an idea, because it woul allow me to reuse a handler that is unchanged between two API versions.... Just an idea, I need to chew on it a little...

Anyways: Mariano and Esteban: Thanks a million, your comments are worth their weight in gold ;-)

Joachim

Esteban Maringolo

unread,
Apr 23, 2021, 9:31:52 AM4/23/21
to va-sma...@googlegroups.com
I have versioned APIs using that approach.

So if you look at WAAdmin class>>#register:at:in:, you'll see that it will create all the intermediate dispatchers (/api/ in this case). so you'll end up with a handlers structure like:

api (WADispatcher)
  \_ v1 (WARestfulHandler)
  \_ v2 (WARestfulHandler)

Best regards!

Esteban A. Maringolo


Reply all
Reply to author
Forward
0 new messages