REST URL parameter

  
I can consume a Rest api method with the following url

GET http://restserver.api/rest/Method/{id}

Is it also possible to expose such a method this way? so the {Id} is not a query-parameter ( Method?id={id} ) but part of the url.

Kind regards,

Matthias 

Hi Mathias,

Not at the moment, but it will be possible in the next revision.
Should be released (the RC) in a one or two weeks.


Regards,
João Rosado
yay, sounds great!

So, is it already in the latest version (9.0.1.35)? Because I can't seem to find it...
Solution
Hi Killian,

Yes it's available in 9.0.1.35.
See this video: http://screencast.com/t/hpGLsuIxIm9V

I recorded it earlier today regarding to having multiple methods on the same URL with different HTTP Methods. But it's similar as it uses the same property. Just add a /{Id} to it.

Regards,
João Rosado
Solution
Hi João,

Fortunately, Service Studio gives a nice error message when there's no correspondence between the parameter and actual input parameters :). Btw, Service Studio does *not* complain in the consuming eSpace about non-mandatory parameters.

EDIT: Forgot to thank you for the swift response. So thanks!
Hi again,

Can you explain what you mean about the consume?
From what I remember inputs in the path are mandatory (just on my phone, so can't check atm)

We are also planning improvements on the Consume REST API feature, so any suggestions are welcome.

Regards,
João Rosadl
Well, I just noticed that while Service Studio gives an error when trying to expose a REST API method when the Id-parameter isn't mandatory, when you consume a RESP API method with an Id-parameter it doesn't warn when it isn't set to mandatory.

As for improvements of the consume, is there any reason why Basic Authentication needs a static Username / Password? I'd like to use basic authentication with a Username / Password based on the user credentials.
Ha,

Right, the consume is a lot more permissive than the expose, because it needs to fit any external service.
So a url like  /MyExternalService//  instead of /MyExternalService/112/  is still valid, so we allow it.

For the expose we decided to restrict it a bit to keep the mental sanity of both you and us when trying to find out what method conflicted with what (and why). So placed the mandatory restriction there.

Example:

Method1  : /MyService/
Method2 :  /MyService/{Param1}/
Method3 :  /MyService/{Param1}/{Param2}/

If all those parameters are optional, what method is called on /MyService/  ?

The actual answer is that both WebApi (.NET REST framework) and Jax-RS (Java REST framework) specs say that trailling / are optional, so they all fail to compile complaining it is ambiguous :)



Regarding the Basic Authentication, the main reason it doesn't have that out of the box is to avoid promoting applications having to ask the end-user username/password credentials or even store them.

But anyway it is easy to overcome the problem, just leave them empty and set a input with "Send In" "Header" called "Authorization".
And then create a helper function to build the header value:






Regards,
João Rosado
Thanks! I'll take a look at that, seems easy-peasy :).
Oh, João, one more thing that would be really really really useful re Consume REST API: have the HTTP status code available automatically, so we needn't do OnAfterResponse trickery to get them. Ideally, let the developer decide whether or not an exception should be given on 300+ error codes (imho they are functional codes, like "resource not found", which should not throw exceptions).
Btw, re consuming: I just found that when consuming a POST web service without any content (i.e. no input parameters in the body), a 411 is triggered when the web service is called.

EDIT: Removed stuff that's not true (sorry, didn't look closely enough).
Another thing that seems a bug or limitation: I can expose a PUT with a Boolean in the body, but I can't consume it, as Plain Text needs text, not a boolean.
Hi Killian,

Thanks for your feedback.

Regarding both the 411 issue and the basic datatypes inputs in body, they were already fixed and are scheduled to be delivered in the next major release.

Regards,
João Rosado
Hi João,

Good news on the 411/basic datatypes. For both I've got workarounds, but it's a good thing they're going to be fixed.