In this question, I am told that web API is specifically purposed for making rest services. What are the options for not wanting to follow rest? What are Web API alternatives to REST?
WCF was earlier used to write RESTful services. But, WCF is strongly used towards SOAP based architecture and doesn't fully support (or it is quite difficult to write) the entirety of RESTful architecture.
Hence, WebApi was developed as a lightweight solution to support only RESTful services.
Related
So I'm about to create a mobile application using titanium. I want to use Symfony2 as the server and communicate via rest API's with the client (mobile)
What I am asking is what are the best practices when it comes to designing my server? and what do you recommend I start with?
Have a look at the FOSRestBundle or the Symfony REST Edition, this should get you started quickly.
https://github.com/FriendsOfSymfony/FOSRestBundle
https://github.com/gimler/symfony-rest-edition
As far as RESTful API endpoint design and the data your API will transfer, I really like this guide:
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
Granted, this is more of a generic "How do I REST API?" guide, but I think it's useful in a situation like yours.
I am in the process of rewriting the architecture for an existing application that will be hosted on Azure and have at least two API's - one public, and the other private for internal RESTful-related CRUD calls.
The main technology stack is ODATA, WebAPI2, C#, MVC5, EF, AngularJS. My thoughts were that the RESTful endpoints would all be exposed through the Azure Web Role (just like any other URL).
In reading more about OWIN and using it with the WebAPI and the Azure Worker Role, it seems like exactly the same thing, but as a service.
Is there any advantage to going this OWIN route (where come to think of it, I could even write a WCF service to do the same thing) rather than the web-based RESTful API calls?
I'm looking for some reasons why I should go through the exercise of moving to a service-based API.
Technology speaking
For your public API, I would suggest to do it with Owin in a RESTful way. This will create a facade to your internal systems.
Internally, WCF will offer better performances.
PROS
Maintenance is way easier with a good plan. Because of its decentralized design, the risks due to refactoring are contained in a specific context. Maintenance is all about minimizing and controlling risks related to changes.
Those links are more talking about SOA but I'm sure you can extract the information needed from them:
Services by Contracts
Amazon SOA
Amazon Shareholders Letter
CONS
You should be aware though since it also has drawbacks. You will need solid Unit Test, Logging and Versioning strategies.
Hope this helps a little. I tried to keep only the essentials since a complete answer to this question could be published as a book.
I've just started on a small project to create some REST services using Google App Engine and Java. I'm new to both technologies, but I've done some reading on both. I'm familiar with SOAP (have used them previously), and I think I understand the conceptual differences between REST and SOAP.
Currently I need info regarding two things:
1) I'm trying to find some tutorial which builds a simple REST service from scratch for deploying on Google App Engine (GAE). The simpler the better, but it should have at least a few routing options. I don't need any UI, if that matters.
2) Which RESTful Framework should I use with Google App Engine. Again, simplicity is what I'd like, and something which has tutorials and a newcomer can easily grasp.
My ultimate goal is to just write a REST wrapper with multiple routing options, which eventual consumes some pre-existing SOAP services and returns their results.
Have you checked out Google Cloud Endpoints for creating a REST service? Its pretty simple and straightforward, also has support for OAuth.
I would give Jello framework a try. It offers a clean, and simple to follow, JSON format and provides a very powerful and comprehensive RESTful implementation that follows the OData specification.
Here is Jello's REST development guide: http://jello-framework.com/guide/rest.html
I'm a newbie to RESTful webservices and I'm trying to create a RESTful webservice in one of our previous SOAP based webservice hosted in axis2c which by it's documentation says that one can host both RESTful webservices and SOAP based ones at the same time?
If so will the RESTful webservice be truly RESTful?(My doubts are on this one). I'm finding it hard to find tutorials for building RESTful webservices in axis2c apart from their documentation. If there are some good tutorials out there that you know of please post them.
To determine whether or not a REST service is truly RESTful, one must measure the service against the six constraints of a RESTful Web Service:
http://en.wikipedia.org/wiki/Representational_State_Transfer#Constraints
If your web service meets the 5 criteria (one is optional) then the service is truly RESTful.
In relation to this question, I have a follow up question that I am still confused over. I have been asked to compair REST vs Web Services. From what I have learnt about REST, it is not a web service, therefore how can you compair the two? What does the question mean when it says REST in this respect?
REST is an architectural pattern for web services emphasizing the usage of URIs as resources with a small set of operations that may be performed on them (usually PUT, POST, GET, and DELETE). I'm guessing you are being asked to compare REST to the ws* standard web services which utilize a lot of other technologies (including SOAP, though SOAP itself is not a web service, it is just a protocol that happens to be used in ws* web services).
REST can be used to provide web services just like databases can be used to store names and addresses. REST is far more general purpose than simply a way of providing a web API.
REST is useful for building distributed systems. However, many people use Web Services (note the capitals, this usually denotes SOAP, WS-*) for building distributed systems.
Wow, I just saw the homework tag. That is one seriously mean question. There are industry veterans who could not come close to answering this question.
A more accurate question would be: Compare REST using HTTP versus RPC using SOAP for building distributed systems.
They probably mean REST verse SOAP. They're all web services in concept.
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.
Hence REST is just an API (an interface that allows you to build on the data and functionality of another application) architectural style.
On the other hand, web service is a network-based resource that fulfills a specific task. Yes, there's overlap between the two: all web services are APIs, but not all APIs are web services.