RejectedSoftware Forums

On Mon, 25 Jul 2016 15:42:27 -0400, Steven Schveighoffer wrote:

I am struggling currently to understand the way this is supposed to work.

Let's say I have a widget that I want to allow fetching and setting,
with registerWebInterface.

class WidgetInterface
{

void getWidget(int id);

}

This works awesome. I go to my web page, route of widget?id=1 and it works.

But then I want to update a widget:

void updateWidget(int id, string name)

Unfortunately, the route here, is still widget. Yes, it uses a different
method. But I have a dilemma here. I like the name "update", it's a good
verb for this method. However, vibe is making me either use UDA to "work
around" this limitation, or find some other nice term to go between
update and widget that reads well both with and without the method
prefix (I like my routes to be self explanatory).

For add, you can do addNewWidget, and newwidget seems reasonable,
because new is somewhat describing a "verb" even though its CS-related.
I can't think of something similar for update. updateExistingWidget
translates to existingwidget, which doesn't convey the action very
well. And there are multiple actions you can do on an existing widget.

Is there a reason we can't specify that the verb should remain in the
route name when registering an interface? Am I missing a better way to
do this? Are there best practices on this somewhere?

Sounds like the web interface is following the REST pattern as well. Not sure if the MethodStyle enum [1] affects this or if it's only for the case convention.

According to REST, the best practices are that one should use what the HTTP protocol provides instead of making up your own protocols/conventions. That would lead to more consistent routes and API's.

Ruby on Rails favors RESTful routes.

[1] https://vibed.org/api/vibe.web.common/MethodStyle

/Jacob Carlborg

On Tue, 26 Jul 2016 08:42:06 -0400, Steven Schveighoffer wrote:

I am using sessions to do authentication, so it can't be RESTful.

The resource would be "session". When creating a "session" resource you would store the data in the session. When destroying the "session" resource you would delete the data from the session. This is an example of a session controller in Rails:

class SessionsController < ApplicationController
  def new
    # renders a login form or similar
  end

  # login form posts to this method/route
  def create
    user = User.find_by_email(params[:email])
    if user && user.authenticate(params[:password])
      session[:user_id] = user.id
      redirect_to root_url, :notice => "Logged in!"
    else
      flash.now.alert = "Invalid email or password"
      render "new"
    end
  end

  # when logging out this method will be called
  def destroy
    session[:user_id] = nil
    redirect_to root_url, :notice => "Logged out!"
  end
end

http://railscasts.com/episodes/270-authentication-in-rails-3-1?view=asciicast

One might ask, why do you care about the route names then? Well, I just
do :) I want the route URLs to look intuitive when I'm testing them in a
browser.

I think it would be nice to have an attribute that says "leave the prefix".

If you think it's easier you can manually set up the routes. There's even an example how to do that and using sessions: https://vibed.org/docs#http-sessions

/Jacob Carlborg

On Tue, 26 Jul 2016 12:08:46 -0400, Steven Schveighoffer wrote:

I'm going off of stackoverflow's recommendations:
http://stackoverflow.com/questions/319530/restful-authentication

"To be honest, a session managed on the Server is not truly Stateless."

Nobody said you had to store the session on the server ;). It can be stored in a cookie.

But in any case, my understanding is that vibe's registerRestInterface
does not provide easy ways to get at the HTTP session data. I'm new to
vibe, so maybe I can do it in a better way.

But I want to try and stay true to the definition. If it's almost REST,
but not quite, then I'll just use the web interface. It seems to be the
most usable. I don't want to fight the goals of vibe.d's REST system.

Yes. registerWebInterface seems to behave very similar to registerRestInterface and follows the REST pattern. This was all a reply to that sessions can't be RESTful. Or were you referring to that you can't use registerRestInterface and access sessions in vibe.d?

http://railscasts.com/episodes/270-authentication-in-rails-3-1?view=asciicast

Not too interested in RoR stuff, but thanks.

Well, I just want to show that indeed sessions can be RESTful. I could have avoiding giving an example, but I though it would be more useful with an example.

Ugh. I want as much introspection as possible :P

What I've done as a workaround is to rearrange my routes. Instead of
getWidget, I use the route widget/op, where op is the name of the
operation. It reads better to me, and is funky enough that it doesn't
have cringeworthy grammar in English :) If I need to leave the prefix, I
can just rename the path.

I'll get used to it I suppose...

You do have a couple of options now. If none of them fits your need then the question is if you really should be using registerWebInterface.

Note, I'm not against adding an option to "leave the prefix". I'm just trying to help to come up with alternatives.

/Jacob Carlborg

On 2016-07-28 23:32, Steven Schveighoffer wrote:

Just FYI, I gave in :)

Hehe :)

I'm now using registerRestInterface after all. I realized that the
client I'm working with has great support for JSON serialization, but
would require manual work to set up traditional POST data. Many of the
other features of the rest interface system make it more attractive than
I first thought. Yeah, it's not exactly REST, oh well :)

I'm using the @before trick to manage the session, and it should work
fine for my purposes. I've also decided that specifying methods as UDA
isn't so bad.

Thanks for the discussion and recommendations!

Glad I could help :)

/Jacob Carlborg