I am studying on Resful web services with RestEasy API. In docs of API at chapter 8 there is a topic called "Linking Resources." I read that chapter several times and I can not understand what it is.
What is linking resources?
What can we do with it?
Why do we need it?
I believe it refers to level 3 of the Richardson Maturity Model:
Hypermedia – resources contain links to related resources and
collections, and also links to perform actions on the resources
themselves. APIs are now self-documenting and discoverable.
As to why do we need it, here's a much more details answer than I could ever write.
Of course, all these are theoretical notions - but at the same time your question doesn't seem to be too tightly coupled to the actual RestEasy implementation details.
Related
I'm searching for a topic for my bachelor thesis. I talked to a research assistant and he told me that there might be a lot of other operations (e.g. BI-functions like trigger actions or calculate something) except of CRUD that you use REST for. He offered me two topic. One of them is to expand a benchmarking framework to be able to handle these operations.
I did some pre-research but couldn't find anything in this direction.
Since the topic sounds really cool I wouldn't like to reject it that fast.
I need a hint what kind of abstract operations there might be.
Thanks
the rest operations are based on HTTP Protocol which support several methods (OPTIONS,HEAD,GET,POST,PUT,DELETE also TRACE and CONNECT but not used in REST API)
see https://www.rfc-editor.org/rfc/rfc2616 for more details
Can I do with REST any other Operations than CRUD, e.g. BI-functions?
Especially in the context of thesis work, you are going to want to start from chapter 5 of Fielding's disseration.
If you read carefully, you'll discover that REST is an architectural style, and the "killer app" built using that architectural style (mostly) is the World Wide Web.
So the question "Can I do BI-functions with REST?" is closely analogous to "Can I create a web interface that implements the application protocol for BI-functions?"
Given that the arrival of the Web was a catastrophic event for legacy information systems generally, I'm going to guess that the answer is "yes, of course". But what form that might take, and what sorts of standards might emerge from the work is not obvious to me.
Does REST constitute a Service Oriented Architecture?
SOA and REST are both architectural styles. They have some common architectural styles they draw from (like Client/Server and Layered System) but the also draw from some different styles that aren't shared (e.g. SOA builds on Pipes & Filters and REST on Uniform Interface).
You can build RESTful SOA's but you'd have to adhere to the principles of both to that.
Also don't confuse REST with just using HTTP technology for implementing SOA.
You can see this pdf which contains chapter 10 of my book. Section 10.1 discusses REST & SOA in more detail
This is a pretty philosophical and a very general question that is very likely to be removed, I'll share my thoughts though.
There is a concept called Resource Oriented Architectures, defined by Richardson and Ruby in RESTful Web Services (O'REILLY 2007). I think the term is the best one to describe the most common approach to REST.
The main idea of ROA is defined by four concepts:
Resources
Their names (URIs)
Their representations
The links between them
and four properties:
Addressability
Statelessness
Connectedness
A uniform interface
When talking about RESTful Web Services, I think it's good to stick to the term ROA and all information it carries.
As for SOA, the name is extremely vague. Some people think it should be reserved for Big (SOAP-based) Web Services only. Personally, I consider ROA a variant of SOA. The authors of the book, hovewer, refuse to make a final statement.
Service-Oriented Architecture (SOA) is perhaps the least well-defined term of all, which
is why I called it out in Chapter 1 as a term I wasn’t going to use. I know of no litmus
test which indicates whether a given implementation is SOA or not.
Richardson & Ruby, RESTful Web Services, O'REILLY 2007
EDIT
The book quoted here has been made available under a Creative Commons License and is now possible to download free of charge.
I read Bill Burkes book "Restful Java with JAX-RS" (2009) and when he wrote about frameworks (RESTEasy, Apache CXF, Jersey), specially about frameworks which support the client side implementation, he said:
There is a lot
of interest from the JAX-RS specification lead and expert group members to get a
standardized client framework baked into JAX-RS 2.0.
Am I right when I say, there isnt a standardized client framework yet? Will there ever be one?
I thought about writing a 60 pages long work about the different frameworks with regard to client side implementation. At the end maybe a prototype of an own implementation, with some good ideas. Do you think it's a good issue to discuss about? Do you have ideas what else I could consider in this discussion?
I think, you need to be very clear on what the objective of such a paper would be. Ie. what the interesting application of your findings would be.
Do you e.g. intend to submit it as input to the JAX-RS specification board, or publish it as a white-paper for solution architects or even as a scientific paper? If not, then I agree with Donal Fellows on that 60 pages is way too much, and that you otherwise probably will need more than that to establish your methodology, describe the experiments including how they relate to the objective, analyse your findings, and so on. And if you also want to try your own hand in creating a client framework, then you will quickly come close to the extend of a postgraduate thesis...
On the other hand, am I certain, that we are many practitioners, who are reluctant to embrace JAX-RS as long, as there are no mature ways of consuming the services it enable us to produce. It should however be possible evaluate the different options in a more accessible form than a 60-page report.
If you decide to go ahead with making some sort of paper about this, I (too?) will be interested in seeing the result.
Also, I am curious of, whether any of the JAX-RS frameworks supports "dynamic" clients based on runtime binding of URI templates delivered from the server.
Update: This question was inspired by my larger quest for mapping ontologically the whole software systems architecture enchilada. I've written a blog post about it, and hopefully it will help clarify what I'm after.
Many, many, many frameworks and stacks that's event-driven have too much variation for my little head to get around. Is there somewhere some resources that defines the outline of a reasonable Application Event Model, what events there are, and what triggers are most common?
I've got my own framework with a plugin and event-driven architecture, but I want to open-source it, and as such would like to make it closer to some common ground as not to alienate people.
So to clarify; this is for an application, meaning setting up the environment, the dependencies, the data sources (like databases), and being a MVC framework setting up the model, the view, launching controllers / actions, and in the GUI various stages of the interface (header, content, columns, etc.).
Ideas? Thoughts? Pointers? (And I've made it language and platform neutral at this point)
I read your blog entry, which btw I found an extremely interesting read, but... this question does not seem to reflect the broadness of the issue you are presenting there.
What you are after is very abstract and theoretical. What I mean to say is that if you tie any of those ideas to actual technology you will find yourself 'stuck' with it. This is why many of us are reluctant to use any framework. Especially the 'relabeled' products suddenly claiming to conform to the trend. We choose mainly on the basis of what appears to be needed to reach a predetermined result.
Frameworks (or tools in general) that target the application architecture domain distinguish themselves primarily by the amount of responsibility they are designed to take on. Spring for example only deals with the concept of decoupling and is therefore easily adopted and useable in many situations. The quality of any framework is expressed in terms of how well the designers of such frameworks were able to keep their products within the boundaries of that responsibility. Some front-to-end products will do exactly the opposite, code generators being among the 'worst' of them.
To answer your question at the top of this page, I do not think there is a framework that does what you want at this time and I do not think there is a single model of how applications (should) work. Keep in mind though that the application architecture domain deals with technology more than it does with concepts. In other words: If it works and meets the requirements, then you're pretty much done.
That said, you might find something of value in agent-based systems.
Heh. Most developers pick the major framework they like the tools for and stick with it. That's usually the winning strategy. I sympathize with your desire not to marry a single vendor.
Keep in mind however, that in developing your own framework, you're going to end up tied to a single vendor anyway. :-)
Is there somewhere some resources that defines the outline of a reasonable
Application Event Model, what events there are, and what triggers are most common?
I don't think so.
From what I see, there are two kinds of models out there: those with a real framework with which you can make a working data entry dialog, and abstract meta-meta-models that are optimized for modeling themselves.
Try surveying a few current frameworks that have good documentation online and cross-reference the major terminology in a spreadsheet. It's an interesting exercise.
I'd have a look at Spring for Java, and the XT Framework Spring module (http://springmodules.dev.java.net/docs/reference/0.9/html/xt.html), which apparently supports event-driven architecture, as starting points. Spring has an MVC framework (inc. convention-based routing to controllers), db configuration (for Hibernate, particularly), plus full dependency injection support. There's also a mechanism in Spring for modularising your web apps, called Spring Slices. And it can be integrated with Jersey for building RESTful apps.
(Unfortunately, I tried to provide links to everything, but this place only lets new users post a single link. So you'll have to do some googling :) )
At work I am responsible for writing specifications quite often and I am also the person who insisted on getting specifications in the first place. The problem is I am unsure how specifications should look and what they should contain. A lot of the time when my boss is writing the specifications (we are both inexperienced in it) they put in table names and things that I don't think belong there. So what is a good way to learn to write a good spec?
EDIT: Should a functional spec include things like assuming I am specifying a web application, the input types (a textbox, dropdown list, etc)?
The most important part of development documentation in my opinion, is having the correct person do it.
Requirements Docs - Users + Business Analyst
Functional Spec - Business Analyst + developer
Technical Spec (how the functionality will actually be implemented) - Sr. Developer /
Architect
Time estimates for scheduling purposes - The specific developer assigned to the task
Having anyone besides the Sr. Developer / Architect define table structures / interfaces etc. is an exercise in futility - as the more experienced developer will generally throw most of it out.
Wikipedia is actually a good start for the Functional Spec, which seems similar to your Spec - http://en.wikipedia.org/wiki/Functional_specification.
There's a great chapter in Steve McConnell's Code Complete that runs through specification documents and what they should contain.
When I was tasked to build an Architecture and Business Analysis team at a company that had never had either, I used McConnell's spec chapter to create the outline for the Technical Specification document. It evolved over time, but by starting out with this framework I made sure we didn't miss anything and it turned out to be surprisingly usable.
When writing specs, a rule of thumb I follow is to try to have technical documents always start from the general and move to the specific -- always restate the business problem(s) or goal(s) that the technical solution is being developed to solve, so the person reading the spec doesn't need to go to other documents to put it in any sort of context.
See Painless Functional Specs by Joel Spolsky.
Some of the things he says every spec should have:
A disclaimer
An author. One author
Scenarios
Nongoals
An Overview
Details, details, details
Open Issues
Side notes
The important thing is to get something written down rather than worry about the format.
Buy Books:
Requirements Engineering by Ian Sommerville & Pete Sawyer ISBN 0-471-97444-7
or
Software Requirements by Karl Wiegers ISBN 0-7356-0631-5