The WSDL 2.0 Primer has two examples (sections 5.3.3 and 5.3.4) mentioning REST, but a core constraint of REST is HATEOAS and those examples have no hypermedia controls.
Is it possible to describe hypermedia controls with WSDL (like one would with Hydra, for example)?
Related
I want to create a set of REST API endpoints to expose various data sources. I want my endpoints to comply with the Richardson Maturity Model, specifically with support for HATEOAS.
I've looked over both JSON-LD and JSON:API and they both seem to be a good fit in that they can both equally support REST and HATEOAS, however JSON:API has a bunch of other features which are more 'gRPC-like'.
Are there any clear advantages to using JSON-LD Vs. JSON:API for REST endpoints? What are the feature differences which are applicable to REST?
Just to clarify what I mean by RESTful, it should satisfy the following constraints, taken from here:
Uniform Interface
Stateless
Cacheable
Client-Server
Layered System
Code on Demand
From my research, I believe that they aren't RESTful, primarily because :
They do not use HTTP verbs.
They do not use HTTP Response Codes.
They does not follow principles of REST connectedness which is based on HATEOAS.
Refer this resource for more information about data above conclusions are based on.
Some resources like these seem to suggest these frameworks can be used/implemented as RESTful.
Please refer to resources you're basing your answer on. This question is intended to clear the misconception about the topic strongly citing official resources.
Are RPC frameworks such as Apache Thrift or GRPC or any other RPC framework RESTful?
Taken in isolation: no.
The definitive reference on REST is Architectural Styles and
the Design of Network-based Software Architectures. Roy Fielding describes the architectural constraints that were developed while working on the web standards (RFC 1945, RFC 2068, RFC 2616, later RFC 7230).
REST is intended for long-lived network-based applications that span multiple organizations (Fielding, 2008)
"The World Wide Web" would be an example of an application built using the REST architectural style.
HTTP methods and status-codes are not themselves a REST constraint. In a REST architecture, the client and server share semantics by exchanging messages, but those aren't required to be HTTP messages. You could replace HTTP with another protocol that conforms to the architectural style, and still have a REST architecture.
Some resources like these seem to suggest these frameworks can be used/implemented as RESTful.
People who understand REST to mean HTTP+JSON are going to reach conclusions that are inconsistent with the web architecture and Fielding's thesis.
In short - HTML does a lot of the heavy lifting in making the web architectural style successful. JSON, in contrast, does not include the semantics of a "link" or a "form" that can be used to communicate to the client which transitions are possible. You need some other semantics on top of JSON to allow the server to communicate to the client which application transitions are possible; either Web Linking or a hypermedia aware dialect of JSON.
As far as can tell, you could use Thrift to create an application that satisfies the REST architectural constraints. But my guess is that it wouldn't be a particularly satisfying experience: Thrift was developed because Facebook needed a system with properties that the Web architecture didn't satisfy.
REST is great for the web. Howver, the stack composed of REST, HTTP and JSON is not optimal for high performances required for internal data transfer. Indeed, the serialization and deserialization of these protocols and formats can be prejudicial for overall speed. -- Leo Schoukroun
URI, HTTP, HTML are easily repurposed, but that flexibility comes with costs. In settings where that flexibility doesn't provide value (for instance, because you are a single organization that controls deployment of the client and the server), then more efficient formats and protocols become more interesting.
It's similar to the trade off that we've made between HTML and JSON -- JSON isn't a useful hypermedia representation; but it's perfectly satisfactory for consumption by the code on demand that has been loaded by our hypermedia representation.
Horses for courses.
REST is by definition not RPC, because the most significant distinction of REST is that it is resource oriented, which RPC is (typically) not.
Furthermore, one should refrain from trying to solve problems that are crying for RPC by inventing some "RPC over REST" solution - Programmers SE is full of these kind of questions.
In fact, such an approach would be upside down: One can implement a REST-based system by means of RPC, but the whole idea why one would want to use REST is on a completely different abstraction plane.
So I'd say the question is (sort of) a category mistake.
I am curious whether HATEOAS is the skeleton of REST. If it is, is HATEOAS a CRUD-based model or not? If not, what is the difference?
I find applications that create CRUD applications from HATEOAS. Is that enough evidence to say HATEOAS is based on CRUD?
i am curious if hateoas is the skeleton of rest
Yes, see Fielding 2008: REST APIs must be hypertext driven.
hateoas is a crud based model or not ?
Not necessarily, no. In the case of the web, the primary hypermedia controls are links and forms. Forms are used to send representations to the origin server, but the semantics of a form submission are not necessarily create/update/delete.
Is there any difference between REST Assured and RESTful web services?
What is REST?
REST stands for Representational State Transfer, which is an architectural style for distributed hypermedia systems, frequently used to build web services that aim to be lightweight, maintainable and scalable.
The REST architecture was defined by Roy Thomas Fielding in his dissertation and should follow this set of constraints:
Client-server
Stateless
Cache
Uniform interface
Layered system
Code-on-demand
The fundamental concept in a REST architecture is the resource and resources can have different representations. For more details, this answer can be helpful.
It's also worth mentioning that the REST architectural style is protocol independent but it's frequently designed over the HTTP protocol because it is largely adopted and well known.
What is RESTful?
A service based on the REST architecture, following the constraints mentioned above, is called RESTful.
What is REST Assured?
REST Assured is a tool that aims to bring simplicity for testing and validating the response of REST services in Java.
What is the main differences between restful and resteasy webservices? Have been working with resteasy and it works with jboss. That's all I know.
What is REST?
REST stands for Representational State Transfer, which is an architectural style for distributed hypermedia systems, used to build web services that are lightweight, maintainable, and scalable.
The REST architecture was defined by Roy Thomas Fielding in his dissertation and should follow this set of constraints:
Client-server
Stateless
Cache
Uniform interface
Resources identification
Resources representation
Self-descriptive messages
Hypermedia
Layered system
Code-on-demand
The fundamental concept in a RESTful API is the resource and resources can have different representations. For more details, this answer can be helpful.
It's also worth mentioning that the REST architectural style is protocol independent but it's frequently designed over the HTTP protocol because it's largely adopted.
What is RESTful?
A service based on the REST architecture, following the constraints mentioned above, is called a RESTful service.
What is RESTEasy?
RESTEasy is framework provided by JBoss to create RESTful services in Java. It implements the JAX-RS specification (the Java API for RESTful web services).
RESTful is a term, it means that the actual service fulfills all of the required REST constraints, while RESTEasy is a framework for building REST services.
RESTful term refers to those systems that conform to the constraints of REST.
Java API for RESTful Web Services is JAX-RS.
Different vendors offers their implementation of JAX-RS and RestEasy is one of them:
- Jersey
- Apache CXF
- JBoss RESTEasy
- Wrapping Up