Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have been unable to make a definitive choice and was hoping that somebody (or a combination of a couple of people) could point out the differences between using RestSharp versus ServiceStack's client services (keeping in mind that I am already using ServiceStack for my service). Here is what I have so far (differences only). The list is fairly small as they are indeed very similar:
ServiceStack
Pros
Fluent Validation from my already created service POCO objects
One API for both client and service
Code reads better (i.e. Get<>(), Post<>())
Cons
Some of my strings must be written out (i.e. If I make a GET request with query parameters, I must create that string in my code)
I must create a different class for each Request/Response Type (JsonServiceClient, XmlServiceClient)
RestSharp
Pros
Just about everything can be a POCO (i.e. If I make a GET request with query parameters, I just add the parameters via code)
Switching between Request/Response types is simple (request.RequestFormat = DataFormat.Json/Xml)
Cons
Manual Validation (beyond that found in the Data Annotations)
Two APIs to learn (this is minor since they are both fairly simple)
Code is not as readable at a glance (barely) (i.e. request.Method = Get/Post.. and main call is Execute< T >())
I was leaning towards RestSharp since it tends more towards straight POCO use and very little string manipulation, however I think ServiceStack might be acceptable to gain the validation and code that is more easily read.
So, here are the questions:
Which do you prefer?
Why the one over the other?
I know this is not a totally subjective question, but at bare minimum I am looking for the answer to this question (which is subjective):
Are any of my findings incorrect and/or are there any that I missed?
As the project lead of ServiceStack I can list some features of the ServiceStack Service clients:
The ServiceStack Service Clients are opinionated in consuming ServiceStack web services and its conventions. i.e. They have built-in support for structured validation and error handling as well as all clients implement the same interface so you can have the same unit test to be used as an integration test on each of the JSON, JSV, XML, SOAP and even Protobuf service clients - allowing you to easily change the endpoint/format your service uses without code-changes.
Basically if you're consuming ServiceStack web services I'd recommend using the ServiceStack clients which will allow you to re-use your DTOs you defined your web services with, giving you a typed API end-to-end.
If you're consuming a 3rd Party API I would recommend RestSharp which is a more general purpose REST client that is well suited for the task. Also as ServiceStack just returns clean DTOs over the wire it would also be easily consumable from RestSharp, which if you prefer its API is also a good option.
UPDATE - Using ServiceStack's HTTP Client Utils
ServiceStack now provides an alternative option for consuming 3rd Party APIs with its HTTP Client Util extension methods that provides DRY, readable API's around common HttpWebRequest access patterns, e.g:
List<GithubRepo> repos = "https://api.github.com/users/{0}/repos".Fmt(user)
.GetJsonFromUrl()
.FromJson<List<GithubRepo>>();
Url extensions
var url ="http://api.twitter.com/statuses/user_timeline.json?screen_name={0}"
.Fmt(name);
if (sinceId != null)
url = url.AddQueryParam("since_id", sinceId);
if (maxId != null)
url = url.AddQueryParam("max_id", maxId);
var tweets = url.GetJsonFromUrl()
.FromJson<List<Tweet>>();
Alternative Content-Type
var csv = "http://example.org/users.csv"
.GetStringFromUrl(acceptContentType:"text/csv");
More examples available from the HTTP Utils wiki page.
Related
This question already has answers here:
What is RESTful programming?
(34 answers)
Closed 6 years ago.
What is Rest API, why is it used, and how can I go about creating one and learning more about it? All functions should be of either GET/POST/DELETE/PUT form?
Simply, a REST API defines a set of functions which developers can perform requests and receive responses via HTTP protocol such as GET and POST. The REST API should specify what it can provide and how to use it, details such as query parameters, response format, request limitations, public use/API keys, method (GET/POST/PUT/DELETE), language support, callback usage, HTTPS support and resource representations should be self-descriptive…
REST is a highly scalable and cachable architecture that is ideal for designing APIs. Basic ideas behind REST -
URL and headers should uniquely identify the resource, such that it can be cached.
REST APIs should be stateless i.e. result of an API call shouldn't vary depending on the API calls preceding it. Keeping state across APIs restricts caching and is thus not considered RESTful.
Use appropriate HTTP verbs i.e. GET for read and idempotent requests, POST for write requests, PUT for write and idempotent requests, DELETE for deletion of resources.
Return appropriate status codes that are compliant with REST standards for the ease of use and universal cachability over different proxy layers.
HATEOAS i.e. Hypermedia as the engine of application state which states that most of the URLS shouldn't be hardcoded, instead server-side should guide the client by providing the URLs in its response. The idea is quite akin to how we use websites on our browsers.
REST is a very popular architecture nowadays for development and is an approach to communications between two very different components that is often used in the development of Web Services. Besides, REST does not leverage much bandwidth which makes it a better fit for use over a network. This makes REST a better fit over SOAP because unlike SOAP you do not have to create a server and a client. In case of SOAP you have to separately create a server program to serve data and a client program that would request the data.
Detail Knowledge base can be found at http://srijan.net/blog/rest-api-and-its-utility-real-web-applications
I am really new to programming, and having some trouble understanding the concept of RESTful APIs. I've read about REST and RESTful APIs. I've looked through the questions already asked here in SO, but can't seem to get any better understanding of the subject.
In my network programming class I'm working with socket programming. There are two parts, part A and part B, in the task.
In part A I've programmed a server that responds to GET and POST. The server either retrieves the file asked for by the client, or writes to the file. (HTTP-protocol is used).
In part B I'm to use HTTP to implement a RESTful application. Basically it is a message server with the ability to handle GET, POST, PUT and DELETE. In this part the server is to create and interact with an xml-file. I understand how the methods work. But what I really don't understand is the following:
Why is the server in part A non-RESTful, while it is RESFTful in part B?
REST is an architectural style (not a protocol like SOAP, not a technology itself or even not an implementation, it is basically a set of a rule), This architecture offers some constraints for using HTTP. If you stick by this architectural constraints while using HTTP, it is called RESTful, otherwise, it is not-RESTful.
list of these architectural constraints here.
resource and more details wikipedia
in part A, what you wrote was just a HTTP end point. Its not a REST 'service'. Maybe you can check this link out for more explanation :
What is the difference between HTTP and REST?
Also, this link provides more info related to that - What is the advantage of using REST instead of non-REST HTTP?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
There has been a lot of hype over REST last few years, and I've tried to embrace the principle and understand it's benefits. Some things about REST still elude me, though. I'll try to be concise and to the point:
Can a web application be considered RESTful? What are the benefits of this? I can understand (to a point) advantages of RESTful service, which is to be used by many clients, but what is gained by using REST principles when developing application interface which is to be consumed by HTML/JS frontend?
REST mandates use of verbs which roughly map to CRUD operations and to which the server responds with representations which in turn put client in a new state. Does this imply that ALL actions on a resource must be done through modification/creation/deletion of that and possibly many other related resources? What about "atomicity" of such operations (i.e. transactions)?
REST compliant service is supposed to be self-descriptive (through HATEOAS principle), but the lack of metadata makes it impossible for a client to e.g. create a resource without knowing exactly what fields (and their types) are mandatory. This information must still be provided out-of-band. Is there something I'm missing here?
I could come up with more questions, but it will be enough for now if someone could clarify these points for me.
Some notes about your questions:
1) If your web application is a Single Page Application the simplest way to communicate with the server will be if it is a Rest service.
For a traditional web application I think is better that "controllers" communicate with a service layer using dependency injection.
3) Yes, of course the client needs to know the format of the data it is receiving. But AFAIK, Rest does not give any constrain about how this metadata has to be defined or transmitted.
The HATEOAS principle refers more to the discovering of related resources from a given one.
There exists different conventions to express that relations, see for example:
http://stateless.co/hal_specification.html
2) Every Rest action must be atomic. If you need a some kind of long operation, the usual is to create a resource that describes the operation. The state of the operation is retrieved from that resource, and you do whatever you want with the operation (i.e. Cancel it) interacting with that resource.
See an example of that here.
1.Usually REST architecture is designed when application is going to be used by different
by nature clients(external api consumers, mobile applications etc). In this case development costs will be paid back completely.
Developing truly REST application is not such a simple task to do. So,
if you know in advance that your application is to be used only by your client-side, probably,
you could consider 100% RESTfull approach as an overhead. But it does not mean
that you should not design your application well, you still could use some of REST principles in your application.
For example, stateless application simplifies scaling, REST-style URLs looks good for users and search engines, etc.
2.Yes, in truly REST all interactions should be expressed via standard verbs on resources.
But you could still create Transaction resource to wrap around your transaction.
See great discussion here: Transactions in REST?
3.As I understand nothing prevent you from providing metadata-information in HATEOAS-based response.
This question already has answers here:
What is RESTful programming?
(34 answers)
Closed 9 years ago.
I have been trying to understand what it means for a application or library or framework to be RESTful? For example, why is it said that bottle or flask is RESTful whereas cgi + wsgiref is not?
Could you please explain with a minimal code example to describe a RESTful application?
REST is an architecture design pattern; you can read more about the sundry details at wikipedia.
The idea is to attach meaning behind HTTP verbs (GET, POST are two you might be familiar with) in order to affect change of data. The API is accessed using endpoints (URLs) that represent a specific entity or entity groups.
In short, here is how its supposed to work:
GET to fetch information about a specific entity.
POST to create new record about a specific entity.
PUT update the information of an existing entity.
DELETE to obviously delete the record of an entity.
Well designed application use HTTP response codes (such as the 200 and the 404 that you are already used to) to indicate the result of an operation against an endpoint.
There is a large amount of material out there on creating RESTful APIs and services, and a healthy debate on how people are doing REST right or wrong. I leave researching these up to you.
Any language that has a HTTP library can be used to expose a REST API for existing data, but there are companies like apigee, mashery and libraries like Google Cloud Endpoints that take care of the menial work for you.
For Python specifically, there are many libraries. One of the most popular ones is Django REST Framework which works with django. There is also Flask-RESTful which uses flask.
There is also this question that discusses more REST frameworks for Python.
That you are asking to “build a RESTful application” shows your confusion. REST is a way to model an interface to an application as a collection of (typically HTTP) resources on the web that respond to standard web verbs in expected fashions (e.g., GET to read, DELETE to destroy, PUT to update). What's more, in a high-quality RESTful interface, the resources link to each other in descriptive ways; the client never needs to invent the names of any resource because it can just follow links (or remember URLs it saw earlier; that's also legitimate). Content negotiation is also A-OK; let the client say what format of representation of the resource is preferred, and let the server provide that if it can.
If an application can act as (or within) a web server while seeing sufficient information about the requests (particularly the method, path and other headers) then it can use that to present a RESTful interface. It has everything it truly needs. Some library stacks make it easier than others by providing more support for the various conventions, but that's just a matter of how much work you have to do yourself as opposed to leveraging that of others.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I was under the assumption that REST was a web service but it seems that I am incorrect in thinking this - so, what is REST?
I've read through Wikipedia but still cant quite wrap my head around it. Why to do many places refer to API's as REST API's?
REST is not a specific web service but a design concept (architecture) for managing state information. The seminal paper on this was Roy Thomas Fielding's dissertation (2000), "Architectural Styles and the Design of Network-based Software Architectures" (available online from the University of California, Irvine).
First read Ryan Tomayko's post How I explained REST to my wife; it's a great starting point. Then read Fielding's actual dissertation. It's not that advanced, nor is it long (six chapters, 180 pages)! (I know you kids in school like it short).
EDIT: I feel it's pointless to try to explain REST. It has so many concepts like scalability, visibility (stateless) etc. that the reader needs to grasp, and the best source for understanding those are the actual dissertation. It's much more than POST/GET etc.
REST is a software design pattern typically used for web applications. In layman's terms this means that it is a commonly used idea used in many different projects. It stands for REpresentational State Transfer. The basic idea of REST is treating objects on the server-side (as in rows in a database table) as resources than can be created or destroyed.
The most basic way of thinking about REST is as a way of formatting the URLs of your web applications. For example, if your resource was called "posts", then:
/posts Would be how a user would access ALL the posts, for displaying.
/posts/:id Would be how a user would access and view an individual post, retrieved based on their unique id.
/posts/new Would be how you would display a form for creating a new post.
Sending a POST request to /users would be how you would actually create a new post on the database level.
Sending a PUT request to /users/:id would be how you would update the attributes of a given post, again identified by a unique id.
Sending a DELETE request to /users/:id would be how you would delete a given post, again identified by a unique id.
As I understand it, the REST pattern was mainly popularized (for web apps) by the Ruby on Rails framework, which puts a big emphasis on RESTful routes. I could be wrong about that though.
I may not be the most qualified to talk about it, but this is how I've learned it (specifically for Rails development).
When someone refers to a "REST api," generally what they mean is an api that uses RESTful urls for retrieving data.
REST is an architectural style and a design for network-based software architectures.
REST concepts are referred to as resources. A representation of a resource must be stateless. It is represented via some media type. Some examples of media types include XML, JSON, and RDF. Resources are manipulated by components. Components request and manipulate resources via a standard uniform interface. In the case of HTTP, this interface consists of standard HTTP ops e.g. GET, PUT, POST, DELETE.
REST is typically used over HTTP, primarily due to the simplicity of HTTP and its very natural mapping to RESTful principles. REST however is not tied to any specific protocol.
Fundamental REST Principles
Client-Server Communication
Client-server architectures have a very distinct separation of concerns. All applications built in the RESTful style must also be client-server in principle.
Stateless
Each client request to the server requires that its state be fully represented. The server must be able to completely understand the client request without using any server context or server session state. It follows that all state must be kept on the client. We will discuss stateless representation in more detail later.
Cacheable
Cache constraints may be used, thus enabling response data to to be marked as cacheable or not-cachable. Any data marked as cacheable may be reused as the response to the same subsequent request.
Uniform Interface
All components must interact through a single uniform interface. Because all component interaction occurs via this interface, interaction with different services is very simple. The interface is the same! This also means that implementation changes can be made in isolation. Such changes, will not affect fundamental component interaction because the uniform interface is always unchanged. One disadvantage is that you are stuck with the interface. If an optimization could be provided to a specific service by changing the interface, you are out of luck as REST prohibits this. On the bright side, however, REST is optimized for the web, hence incredible popularity of REST over HTTP!
The above concepts represent defining characteristics of REST and differentiate the REST architecture from other architectures like web services. It is useful to note that a REST service is a web service, but a web service is not necessarily a REST service.
See this blog post on REST Design Principals for more details on REST and the above principles.
It stands for Representational State Transfer and it can mean a lot of things, but usually when you are talking about APIs and applications, you are talking about REST as a way to do web services or get programs to talk over the web.
REST is basically a way of communicating between systems and does much of what SOAP RPC was designed to do, but while SOAP generally makes a connection, authenticates and then does stuff over that connection, REST works pretty much the same way that that the web works. You have a URL and when you request that URL you get something back. This is where things start getting confusing because people describe the web as a the largest REST application and while this is technically correct it doesn't really help explain what it is.
In a nutshell, REST allows you to get two applications talking over the Internet using tools that are similar to what a web browser uses. This is much simpler than SOAP and a lot of what REST does is says, "Hey, things don't have to be so complex."
Worth reading:
How I Explained REST to My Wife (now available here)
Architectural Styles and the Design of Network-based Software Architectures
http://en.wikipedia.org/wiki/Representational_State_Transfer
The basic idea is that instead of having an ongoing connection to the server, you make a request, get some data, show that to a user, but maybe not all of it, and then when the user does something which calls for more data, or to pass some up to the server, the client initiates a change to a new state.