I'm using spring-hateoas:0.18.0.RELEASE with spring-boot:1.2.5.RELEASE
For calling my Web Service and going through HAL links i'm using Traverson Client (API for client side service traversal inspired by the Traverson JavaScript library)
Spring Hateoas Traverson Documentation
It's new for working with Hypermedia and HateoasRest
My question is when do I need to use PagedResources and Resource?
Example I found here Traverson Client examples :
final PagedResources<Resource<Customer>> resources = traverson
.follow("customers","search","findByFirstName")
.withTemplateParameters(parameters)
.toObject(new TypeReferences.PagedResourcesType<Resource<Customer>>(){});
The code I wrote is :
ParameterizedTypeReference<Resource<ProjectJSON>> resourceParameterizedTypeReference = new
ParameterizedTypeReference<Resource<ProjectJSON>>() {};
Resource<ProjectJSON> projectJSONResource = traverson
.follow("projects")
.follow("$._embedded.projects[0]._links.self.href")
.toObject(resourceParameterizedTypeReference);
I know it's not the same thing, but what is the best practice with resources when calling Traverson.toObject() method?
It's simple: you use PagedResources when you are returning lots of items, and you use Resource when you are returning a single item. So when returning many Customer objects you might want to paginate them, and you'd use PagedResources<Resource<Customer>>. For a single customer it'd be Resource<Customer>.
The Resource just wraps the domain object and adds links to it. If you don't need links now and you know you don't need the links in the future either, you could go without the Resource as well.
The PagedResources adds page metadata for selecting the page number and page size. It also allows the server to send the information on the total number of pages and the total number of items. You could ask a paged resource to send you page 2 with page size of 5, and you'd get items 6, 7, 8, 9 and 10.
Related
I use ControllerLinkBuilder to create an index of links pointing to a list of Spring MVC controllers.
For example:
ResourceSupport resource = new ResourceSupport();
resource.add(linkTo(methodOn(ReactorController.class).sendmail(EventBody)).withRel(REACTOR_REL));
This generates:
"reactor": [
{
"href": "http://localhost:12345/main/reactor/sendmail"
}
]
In the example it is a POST to sendmail that is expected!
What is the way to document that a POST is expected ?
When you provide a link, you are pointing to a resource which can be manipulated by the users of your API, not a function they are expected to know how to use.
https://spring.io/understanding/HATEOAS
The last segment applies to your question.
According to the Richardson Maturity Model, HATEOAS is considered the final level of REST. This means that each link is presumed to implement the standard REST verbs of GET, POST, PUT, and DELETE (or a subset). Thus providing the links as shown above gives the client the information they need to navigate the service.
So in your case, if it does not make sense to implement any of the methods but post, you can just let them post to /mail and you may create a separate documentation (like Swagger, Spring REST Docs) to let them know your format of entity.
I am writing a ruby client for the REST API using RestClient gem. While going through examples, I see different code used to achieve basically the same result, without any explanation on the difference.
client = RestClient::Resource.new('https://example.com/')
response = client.get
VS
response = RestClient.get('https://example.com/')
What is the benefit of using Resource class, if I can achieve same thing with get method?
Code reuse. It's especially useful when you're dealing with APIs, and you need to hit the same base urls over and over, with different params and/or paths. As the docs show you, once you build a base resource:
client = RestClient::Resource.new('https://example.com/')
You can access other paths under this resource quite easily:
response = client["/users/1"].get
Which is equivalent to
response = RestClient.get("https://example.com/users/1")
but less typing/repetition.
I want to build a typical mvc app for CRUD of simple items, the api s should be RESTful. The catch here is, that i have a large pallete of items that needs to be initialized. On the server side those items are defined as java beans and the corresponding create form for the item is dynamically created from the field information(data type, validation constraints etc) harvested from the bean.
I am new to REST and just read up about how the urls should be nouns defining the resource and action specified by HTTP verb. In that perspective how to model something like
.../client/showForm?type=xyz from non RESTful way to RESTful one ?? My intention here is to tell the server to dynamically construct and send back a CREATE form for client of type xyz. The obvious problem with url i mentioned above is that it specifies action in the url which, from what i have read, makes it non RESTful.
When I think of REST, I think of resources. I think of data. In other words, I don't think of REST as being something that I would typically use to retrieve a form, which is a user interface component.
REST is an architectural style that is used to identify a resource on a server using a uniform resource identifier, or URI. Additionally, actions performed on those resources identified by the URI are determined based on the specific HTTP Method used in the request: GET, POST, PUT, DELETE, etc.
Thus, let's say you have a Client object. That client object might have the following properties:
Name
Location
AccountNumber
If I wanted to retrieve the data for a single client, I might use the following URI:
GET /client/xyz/ # xyx is the accountnumber used to identify the client.
I would use a GET method, since REST describes GET as being the method to use when retrieving data from the server.
The data could theoretically be returned in HTML, since REST is not a standard but more like a series of flexible guidelines; however, to really decouple my data from my user interface, I would choose to use something platform independent like JSON or XML to represent the data.
Next, when adding a client to the collection on the server, I would use the /client/ URI pattern, but I would use the HTTP Method POST, which is used when adding a resource to a collection on the server.
# Pass the data as JSON to the server and tell the server to add the client to the
# collection
POST /client/ {"accountnumber":"abc" , "Name" : "Jones" , "Location" : "Florida"}
If I were to modify an existing record on the server or replace it, I would most likely use the HTTP Method PUT, since REST guidelines say that PUT should be used if repeating the same operation repeatedly would not change the state of the server.
# Replace the client abc with a new resource
PUT /client/abc/ {"accountnumber":"abc" , "Name" : "Bob Jones" , "Location" : "Florida"}
The general idea behind REST is that it is used to identify a resource and then take action on that resource based on what HTTP Method is used.
If you insist on coupling your data with your view, one way accomplish this and retrieve the actual form, with the client data, could be to represent the form as a resource itself:
GET /client/abc/htmlform/
This URL would of course return your client data for client abc, but in an HTML form that would be rendered by the browser.
While my style of coding utilizes data transports such as JSON or XML to abstract and separate my data from my view, you could very well transport that data as HTML. However, the advantage of using JSON or XML is that your RESTful API becomes platform independent. If you ever expand your API to where other developers wish to consume it, they can do so, regardless of what specific platform or programming language they are using. In other words, the API could be used my PHP, Java, C#, Python, Ruby, or Perl developers.
In other words, any language or platform that can make HTTP requests and can send GET, POST, PUT, DELETE requests can be used to extend or build upon your API. This is the true advantage of REST.
For more information on setting up your controllers to use REST with Spring MVC, see this question. Additionally, check out the Spring MVC Documentation for more information.
Also, if you haven't checked out the Wikipedia article on REST, I strongly encourage you to do so. Finally, another good, classic read on REST is How I Explained REST To My Wife. Enjoy.
We are creating a REST API using OpenRasta and apart from regular GET, POST, PUT and DELETE on all resources, we are also providing GET on resources with plural names. So a consumer of the API can GET, POST, PUT and DELETE on User and also perform GET on Users which will return List<Users>. Now we want the clients to be able to filter and sort it by it's properties and allow to support paging for showing data in paged tabular formats.
Although, I looked at WCF Data Services Toolkit home page and looks like it can be useful but after looking at blog posts and Getting Started page, I couldn't understand how I can use it to solve my problem in OpenRasta.
Or is there anything else simpler that I can do?
OR doesn't support stuff like OData for that functionality, mainly because it leads to very unrestful systems.
If /users is "the list of users", then it is a different resource than /users/1 (the first page of users) or /users/byName/1 (the first page of users ordered by name).
You can of course implement all this easily by registering a URI that has query parameters, as those are optional
.AtUri("/users?page={page}&filter={filter}
And your handler can look like
public List<User> Get(int page = 0, string filter = null) { ... }
I want to use Wicket to build an application, but I have some designers that would like to write/maintain the javascript, and they basically expect 1 JS-segment per page, and a global JS-file.
I think the most natural way to add javascript in wicket is to add it per component (not per page), which would create problems for those designers (fractioned javascript, and having to write it in java-files). Is there a better way to solve this?
(of course, I expect things to work after a partial refresh.)
And a second (related) thing they'd like (and I'd like actually) is the possibility to request information in JSON-format through a static link , is this possible in Wicket?
I started with JSON by making my wicket pages return the JSON, but quickly realized there are better tools for the job, especially if you will have a full web services layer. If you just need a little JSON here and there, always via a GET, then sure, just make a Wicket page.
I ended up using Jersey with Jackson alongside of Wicket. Jersey simplifies the configuration of URLs that can do different things with different http methods (GET/POST/PUT/DELETE), as well as easily parsing query strings, etc. I'd consider going this route for heavier JSON needs.
You can easily run both Wicket and Jersey in the same web application with a little web.xml configuration.
Wicket's built in AJAX support is always stateful and thus accessed with changing URLs. If your designers aren't planning to use Wicket's JS library, it's pretty straightforward to mount a JSON page:
public class JsonReturningPage extends WebPage {
public JsonReturningPage(PageParameters params) {
String json = "{foo: 4711}";
IRequestTarget t = new StringRequestTarget("application/json", "UTF-8", json);
getRequestCycle().setRequestTarget(t);
}
}
Alternatively, you could also implement your own AbstractRequestTargetUrlCodingStrategy to directly return an IRequestTarget from IRequestTarget decode(RequestParameters params) and mount it in your application.
Regarding JS files, I'd try to educate them to use one file per component. This certainly has the advantage of less copy-paste code and simpler maitenance. Additionally, I'd certainly discourage JS in Java code. It's normally only needed to pass data or config to JS , either as variable definitions or method calls. As this data is typically in Java and JS is written by designers, it's time for designers and programmers to team up.
Quick answer to your second question is yes it is possible. Use bookmarkable links to access a resource that returns JSON data.
You can easily use the following code to dynamically communicate with Wicket:
AbstractDefaultAjaxBehavior callme = new AbstractDefaultAjaxBehavior(){
#Override
protected void respond(AjaxRequestTarget target) {
}
};
page.add(callme);
//From any ajaxrequesttarget you can simply append the following code:
target.appendJavascript("wicketAjaxGet('"+callme.getCallbackUrl()+");");
This way you can have an ajaxlink etc... that will transfer the ajaxrequest to the Wicket side. If you want to pass data (though a static link doesn't sound like that) do the following:
"wicketAjaxGet('"+callme.getCallbackUrl()+"&x='+value_to_pass_back''";
//to Read the value in the respond:
String x = RequestCycle.get().getRequest().getParameter("x");
So the url to the callback is dynamically generated (as the callback url is specific to the session) but it is formed like any other url....
To me this is 10 times simpler than building a JSON system on top of wicket instead of using the one built into it.... I use this all the time and it works great for me at least. If your solution is different/better I would like to know why perhaps.