I am trying to understand what exactly a REST-based API is. From what I understand it is just a convention for writing the functions within the API? All functions should be of either GET/POST/DELETE/PUT form? So, for example a function in a REST API could be
public string getLastName(User x)
{
return x.lastName;
}
I am mainly confused about how JSON/XML play a role in this?
Its more than just a convention. The concept behind a REST API is that you access it using the HTTP verbs, and that the functions those verbs have been mapped to perform the described action.
For example:
GET will return data to the caller/sender
DELETE will delete a record
And it goes further, but a lot of it is based on relying on HTTP to provide a level of consistency. For example, in a RESTful service, you might use the Accept HTTP header to request a JSON response or an XML response by supplying the application/json or application/xml values, respectively. This is just a simple example, and it is up to the implementer to decide how their API will work, but it highlights the importance placed on leveraging HTTP.
Why JSON/XML?
Along the same lines, JSON and XML are used because they are widespread and standard ways of representing and transmitting data over the web. JSON (JavaScript Object Notation) is very common in doing data transfer (especially on GET requests) due to most requests coming from JavaScript, and JS can easily interact with JSON without having to do the parsing required when dealing with XML. On the other hand, XML provides its own benefits, such as the ability to use schemas and namespaces. You may already be aware of benefits/drawbacks of each, but that's a separate discussion. The main point is that JSON/XML are the primary ways of communicating data in a REST API due to both of them being the de facto standards of the web.
There are lots of good resources for more information, this MSDN article may be helpful: http://msdn.microsoft.com/en-us/library/dd203052.aspx
There's a lot of confusion and misconceptions around REST. Unfortunately, it's a lot more common to find applications that are doing the exact opposite of what REST means and calling themselves RESTful than real REST applications.
From what I understand it is just a convention for writing the functions within the API?
No, REST is not just a convention for writing functions within the API, nor it's directly related to SOAP or HTTP as other answers here say. REST is a software architectural style inspired by the successful design decisions made for the web itself. To put it in simple terms, a REST API should work like a website does.
When you enter a website, you go to a homepage having an idea what the website is about, and the HTML document will have hyperlinks pointing you to the resources you need. The only out-of-band information are the media-types of the resources themselves, not how to find them. For instance, when you enter StackOverflow, you know what questions and answers are, and you look for links pointing you to them. How your browser render those links, how you choose them and follow them isn't different from other websites, like an email or news website. What makes it different is the media-type of the resources you're after.
That's how a REST API should work. Clients should not depend on any out-of-band information other than detailing what the resources do. They should connect to a home page that returns them links they should follow to do whatever they need. If an API doesn't do this, then it's not REST. Period.
I like to call those APIs "street-REST", because people often implement them by copying what they see in other APIs that also call themselves REST, and by what other people talk about REST.
All functions should be of either GET/POST/DELETE/PUT form?
That's a common confusion, and you'll see a lot of that, including people conflating that to CRUD operations, or that REST doesn't allow any other verbs, etc. That's bull.
REST is independent of any particular protocol, so it doesn't make sense to say functions should follow HTTP methods. REST constrain your applications into an uniform interface, meaning that whatever protocol you should using, you must stick to the standardized behavior as much as possible. If you're implementating a REST application over HTTP, this means your API must stick to the HTTP methods for the client-server interaction, meaning you can't invent other HTTP methods as some applications using HTTP do. If you change the communication protocol, clients need to know that information before entering your API, and that's more out-of-band information.
How you implement this on your code is irrelevant to REST. REST isn't a development pattern or philosophy, but an architectural style.
I am mainly confused about how JSON/XML play a role in this?
There's a lot of confusion on this too. On a REST application you should define abstract entities with states describing all the behavior you need. The API will serve as a channel to transfer media-type representations of those entities between client and server. REST means Representational State Transfer. The URI the client is requesting is an identifier for that resource, and the metadata for that request will tell the server what media-types the client is prepared to accept. JSON/XML don't play any direct role in REST, at all. They are simply one representation media-type that is easier for computers to parse and obtain information, in contrast to formats like text/html, which is meant to be rendered for human visualization by a browser.
For example, take StackOverflow itself. What's a question, in the abstract sense? It's a request for information. How that abstract resource is formally defined? There's an author, there's the actual text of the question being asked, there's the upvotes and downvotes, the comments and possible answers, etc, all of which are also abstract resources with their own definitions. The actual data is stored in a database somewhere, and when you request your homepage, it returns links with URIs identifying those questions. Take this question for instance, it has the URI http://stackoverflow.com/questions/24092517. When I want to read that question in a pretty document rendered on my browser, I will request that URI, but telling the server through the Accept header that I want a text/html representation, and my browser knows how to render the HTML into a pretty page. On the other hand, when I want to request that question to store it back on a database, for instance, I don't need all the cute stuff needed to render a pretty document page, so I ask a format that's easier to parse and doesn't contain a lot of unnecessary information, like JSON or XML.
Most people who build street-REST APIs understand this point, but they miss the most interesting part, which is that you're not limited to media-types that already exist. You can create private media-types that only exist within your API, or your company's ecosystem of applications. So, for instance, instead of calling the media type of all JSON documents application/json, no matter the content of them, we could have custom media-types that reflect more accurately that particular type of resource. So, we could have a application/vnd.stackoverflow.question.v1+json for StackOverflow questions represented in a JSON format. Once you do that, instead of wasting time documenting operations already standardized by the communication protocol, you should focus on documenting that custom media-type and how to interact with it, independently of the communication protocol. Once you have that clear, clients can interact with your services using any protocol available.
If you understand these three main points, you understand what REST is about. By using hyperlinks as the engine of your application state you're not tied to any particular point in time of your implementation. Your server can evolve at will, you can change URIs as much as you want, and clients won't break. By sticking to the standardized protocol, it's easier for generic clients to make use of your API, not to mention that it's easier for developers to understand how to integrate if they already know that you won't break the protocol. By focusing your design and documentation efforts on your media-types, not on protocol details and URI semantics, you're avoiding introducing more out-of-band information needed to drive your API, and your clients are also more resilient to changes.
REST API's act as middleman to deliver data packets between the web service and an application wanted to use some resource from web service for its operations, in order to do so Json comes into play, which helps in data transfer/communication over the channel. When one's application wishes to get list of resource, it actually get complex data or queryset from database which turn into simple data type with serialization and then turn into json to travers the channel.
RESTful API is much more than just the convention of writing functions.
The abbreviation REST stands for "REpresentational State Transfer".
REST APIs are used to call resources and allow the software to communicate based on standardized principles, properties, and constraints. REST APIs operate on a simple request/response system. You can send a request using these HTTP methods:
GET
POST
PUT
PATCH
DELETE
Also, REST APIs can include endpoints, headers, URL parameters, and the request body.
The endpoint (or route) is the URL you request for. The path determines the resource you’re requesting for. Think of it like an automated answering machine that asks you to press 1 for service, press 2 for another service, 3 for yet another service, and so on.
I am mainly confused about how JSON/XML play a role in this?
When you send a request to an endpoint, it responds with the relevant data, which is generally formatted as JSON, XML, plain text, images, HTML, and more.
I am mainly confused about how JSON/XML play a role in this?
JSON/XML are called streaming data format. There are others but over the years these two became so popular because of low latency they provide. XML is probably still little bit more popular than JSON, but JSON is more compact.
Also another main reason to use them is because they are both supported by almost all languages and their frameworks.
Good evening/morning everyone,
before posting this issue, i've been sending my objects with a traditional way from the client side ( aspx page ) to a WCF data service, the approch i've been using was to convert all attributes to a string and send them after joining them, and in the server side i split the string chain and i construct my object and store it. now by working i found that this method is no longer udapted to what i'm planing to do and it will take me much time. so i've decided to find a way of serializing my xpo objects and send them to the service. been browsing google before coming up to SOF but i didnt find a good tutorial for someone not much familiar with serialization mechanism.
please give me some track to a solution which will reduce lot of time.
i think its a good point to descibe the architecture of my project:
i have a asp web application which contains some pages, and in the server side i have a wcf data service(5.0) which contains all my methods, i'm using XPO as a ORM and all my objects inherit from xpobject.
Thank you in advance and by the way i want to thank the mods/admins/members of SOF for their work helping dummies/intermediate and even experts.
From a performance perspective, it is not recommended to serialize/deserialize the object graph with XPO. Instead you should either serialize the datastore or serialize the object layer.
That said, if you need to serialize objects for import/export, have a look at the eXpand module.
As with all things DevExpress, the best place to ask questions is the support centre.
I'm doing an program, which is running on an local system, with no internet access. Is it possible to create my own custom Web Map Service (WMS) server, using C#. I no that there are free open source system's. But i like to have full control.
Thanks Morten Starck
That is very possible, but you might be in for a headache or two before you are done. The implementation specification and more is available from the Open Geospatial Consortium at the url below.
http://www.opengeospatial.org/standards/wms
It's quite a large specification but you might be able to get away with implementing only the parts you really need and leaving some of the more specific stuff out. You will of course also need to parse and render the map data from some source which might be your largest problem (for which I really would suggest you have a look at SharpMap, http://sharpmap.codeplex.com/ instead of rolling your own).
I have an Linq Expression and I want to convert it to a querystring for REST, i.e.
public IQueryable<Organisation> Organisations;
...
var organisations = Organisations.Where(x => x.Name == "Bob");
becomes
http://restservice.com/Organisations?$filter=Name eq "Bob"
I did find one eventually in Linq2Rest (also a NuGet) which seems to fit the bill. Doesn't support OAuth but would be possible to build this in.
If you are control over the datasource, it's OData what you are looking for.
A google-searched brought HttpEntityClient up, although I don't have any experience with it but it looks useful.
I guess you could also write your own implementation, because frankly, rest-apis don't have to follow a certain standard when it comes to filtering, ordering etc...
PocoHttp can do exactly what you want. Moreover, it can do the call to the service and deserialize entities for you.
You can also easily modify its ODataProvider to support additional OData native functions (length, startswith, etc.)
Early pre-release versions of the OData Library had a query string parser, but expression building was never fully implemented, and the feature was then dropped. It's major hole in the library, since without it, you are left with payload and some header support only.
Fortunately Linq2Rest does exactly what you need, with one line of code:
var organisations = Organisations.sources.Filter(Request.Params).OfType<Organisations>()
The cast is necessary because a query string can select against the collection, producing a different collection of types. If you are only predicating on properties, then you don't care about that.
I found that DataServiceContext developed by Microsoft works much smoother than Linq2Rest and HttpEntityClient third party libraries mentioned here.
Documentation is also much better. The downside is that DataServiceContext works with XML only (no JSON).
But both WebAPI OData REST services and WCF Data Services can return XML, if it requested by a client in HTTP header. Because XML support takes no additional development work, lack of JSON support is unlikely to be an issue.
There are LINQ to REST examples using DataServiceContext: http://msdn.microsoft.com/en-us/library/windowsazure/dd894039.aspx
try Odata
The Open Data Protocol (OData) is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today. OData does this by applying and building upon Web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores. The protocol emerged from experiences implementing AtomPub clients and servers in a variety of products over the past several years. OData is being used to expose and access information from a variety of sources including, but not limited to, relational databases, file systems, content management systems and traditional Web sites.
EDIT 1:
take a look at here also:
http://paulhammant.com/2012/02/13/client-side-mvc-frameworks-compared/
The question might sound weird, but I am planning to create a asp.net website, which when fully done, will ideally cater to all countries.
I am currently in the architecture phase.. and is there anything that I should keep in might when doing this?
like
saving all datetime fields in utc
using user's timezone to display all time related data
all labels in the website to be localizable
is there anything else??
thanks,
Chris
A few additional points:
Some languages read from Right to
Left (Hebrew for example), which
will affect your UI.
Make sure your datastore supports
unicode (NVARHCAR vs VARCHAR).
Provide an easy way for translators
to contribute content. Usually means
creating a Data Driven Resource
Provider.
Internationalization and Localization is a good place to start.
You should think about how the localization process will take place. I assume you are not a native speaker in all languages you want to use for your application.
There are several approachs on how to address this: For example, there are companies that specialize in localization, meaning you give them an excel sheet, or an xml file.
You should also think about, where do you want to have all these localizations. Do you only want them in your ASP.net application, meaning in only one place? Then the resource file will be your way to go, because they are easy to handle and easy to send to localization studios.
But if you want to use the localizations in more than one place, you need to store them in a web service or in a database. Keep in mind that using localizations across multiple plattforms (e.g. web site, administrative tools) will force you to write import/export functionality for the used tables. (Because you won't give the localization company access to your database)
I would start by looking here: http://msdn.microsoft.com/en-us/library/c6zyy3s9.aspx.
I also guess you are working on doing a SQL database. If that is the case look at things like using nvarchars.