I am writing some webservices using spring. I wanna know what's the argument to the service methods: domain objects or request parameters? for example a "User" object or a bunch of strings containing name, e-mail, etc.
Depending on your configuration (and the method signature) you will receive unmarshalled objects (Jaxb for instance), the MessageContext and so on.
Take a look in the documentation, you'll find some examples and everything you need to know about the service methods and parameters.
Related
I am developing a restful API. My create Reservation method requires parameters like data, location etc. It also requires a list of People. Those people have name, birthdate etc.
So to pass the people to the API I need to send a nested object to the API. This is something that I usually don't see out there in the API world.
So my question is: Are there any problems with this and should I somehow flatten the parameter object or is it no problem at all to accept a nested object as parameter?
There will be no problems with this but usually its not preferable because consumer of API need to understand the nested JSON and construct while calling. API having simple request JSON and syntax is always preferable.
This type of strategy is totally linked to modeling and coupling with the information-producing system.
In my opnion, if the resources can be structured sequentially as child resources, in this way the navigation and resuabilidad becomes more interesting. To minimize the number of calls a design pattern API Gateway with agragation is being pretty much in today by corporations.
Example:
POST http://api.teste.com/clients/ --> This is going to create a new client resource and returning the new client identification
POST http://api.teste.com/clients/1/addresses
Is it possible to map the different objects to the same url and use different post params to differentiate between the return types?
My API isn't really rest. Everything flows through the same URL but has a parameter "Type" that differentiates the result that should be returned.
'Probably' - it would be nice it you added a few examples to the question (requests and associated responses).
Sending the requests is fine, though you will need to explicitly specify the path / route name to use.
For the response, you will most likely need to use an RKDynamicMapping which will inspect the incoming data and return the appropriate mapping to use.
If you can't tell the 'type' from the response data (instead, you can only tell because of the URL that was requested) then you may need to try mapping into all types and rejecting invalid content using KVC validation, or you might want to change your data model (not enough information in the question to determine which...).
This question isn't about REST, but about using the returned value from an invocation made in #When in the subsequent #Then.
I am looking at using JBehave to test some calls to a REST api. First there is a post to create the user
When I create a user with name Charles Darwin
As I understand REST, and this is what the Atom api does, the id is returned in the location header, e.g. /user/22. So then I want to assert something about the response.
Then user was created with a valid Id
I can do this by creating a member variable in the Steps class and storing the response there, and I have used this approach before, but is this the correct way?
Yes. One needs to store data that can be asserted on in your #Then methods. The simplest way to do this is to have a member variable - but that means that your #When/#Then need to be in the same Steps class. Another way to do it is to have a shared data object that all your Steps use and you can then set it in one method and get it in another. If you just want something generic, you can do a Map<String,? extends Object> as your generic data object. And then if you run with multiple threads, then wrap the data object in a ThreadLocal.
That's what I've seen - and the data object should be setup/cleared with a #BeforeScenario/#AfterScenario method.
I'm getting up to speed with the WCF Web API. I want to expose an endpoint that can accept notes, via the POST method. My issue is, I want to support multiple representations for notes. For example, I might want to accept a note using a custom XML serialization that we're using elsewhere, or as an atom:entry element. I already have formatters that can deserialize these into a Note class (our own custom class) or as a SyndicationItem.
The question comes though, how do I define the method? I've currently got this:
[WebInvoke(UriTemplate = GetNotesUriRoot,Method="POST")]
public HttpResponseMessage PostNote(ObjectContent item,HttpRequestMessage request)
Which fails when starting up:
The service operation 'PostNote' will never receive a value for the input parameter 'item' of type 'ObjectContent'. Ensure that a request HttpOperationHandler has an output parameter with a type assignable to 'ObjectContent'.
I initially tried having two separate methods (with appropriately typed parameters), but they can't share the same endpoint name. The current effort (using ObjectContent) was based on other posts I could find that suggested that it could be a parameter. There is no common base type or interface between Note and SyndicationItem
We're using v0.6.0 of the WCF Web API
You need to have a parameter / return type of type Note and your formatters will (de-)serialize it to / from the required representation.
[WebInvoke(UriTemplate = GetNotesUriRoot,Method="POST")]
public HttpResponseMessage PostNote(Note note)
then in your request the content-type header will determine how the object is deserialised. You don't need to worry about deciding how to deserialise, the decision is made for you, as long as the relevant formatter exists (I've not delved in to formatters yet as json/xml have been enough for me so far)
I'm using Openrasta for my RESTful webservice and I've a small doubt with regards to the method parameters and URI
For example: I've following Setup for user entity.
Configuration:
ResourceSpace.Has.ResourcesOfType<User>()
.AtUri("/user")
.And.AtUri("/user/{userId}")
.HandledBy<UserHandler>()
.AsJsonDataContract()
.And.AsXmlDataContract();
Handler method for PUT:
public OperationResult Put(long userId, User user){}
URI for the same will be http://localhost/User/1
Request body will contain a JSON as below:
{
"userId":1,
"userName":"FirstName"
}
Here, my question is: Defining the PUT method with two parameters is correct or not? If it is right way to do that, then userId parameter in the PUT method will contain same value as User entity property UserId.
And, in the PUT method I need to verify whether these two values are same or not and if they are not same I return BadRequest stating that URI doesn't match with the entity provided in request. Why should we do this explicitly why not it can be handled while processing the request and have PUT method take only User entity as parameter? Am I missing anything drastically or is my understanding about this design completely wrong? Any thoughts or opinions please?
There's a few reasons for it.
First, it's a technical limitation of how URI parameters are processed and matched to inputs one variable at a time. The same gets applied to key/values codecs, so that ought to let you have one User object. but when you use a json codec, we get back a full object, so that would end up overriding User alltogether.
The second one is that I never tried to fix that problem, mostly because combining uri parameters and response bodies leads to a whole bunch of hidden security issues you probably want to stay well clear of.
Last and not least, from a modeling perspective a ReST API ought to use URIs as identifiers and links instead of foreign keys, so if you already have your identifier (the URI), there's little reason why that should be modeled in your entity body.