I am trying to create a Rest web service running on iPhone; I've done my initial research and found
CocoaHttpServer and TouchCode json parser, is there any library / sample code which binds these together into a Rest endpoint?
If it does not exist, how do I go about writing one? Any reference to some kind of design document etc. will really help.
I'm using CocoaHTTPServer and the iOS builtin JSON libraray to have a RESTful service in iVocabulary. First I wrote a lengthy Connection class (the core for handling requests in CocoaHTTPServer) myself. But parsing the URL was kind of complicated.
So I wrote a more generic Connection class that routes HTTP requests to different blocks for different URLs and different HTTP methods. The URL can contain parameters (with : as prefix), that get parsed. That's not a generic REST service per se, but I added (for example) a block for the url "/rest/:entityname" that fetches all Core Data objects of the given entity.
You can find that router implementation in my fork of CocoaHTTPServer on github: https://github.com/chbeer/CocoaHTTPServer
Another router implementation: https://github.com/mattstevens/RoutingHTTPServer
Check RestKit for working with Restful web services.
http://restkit.org/
I recommend RestKit, I have used for over a year now and love it. However I recently learned about AFNetworking from some colleagues that claim it's very lightweight and thus prefer it as an alternative to RestKit, so I am giving it a try soon.
Related
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.
I am trying to create a RESTful web service that accepts JSON arguments and gives out a JSON response.
What I want is to accept HTTP requests made to my URL endpoint.
Something like,
POST /the/endpoint HTTP/1.1
Host: mywebsite.com
{"name":"yourname", "department":"your_department"}
Do a DB read at the backend and give relevant parameters like, say Manager name, salary etc as a JSON object, as the response.
What's the best way to go about it? I was thinking of using Java servlets for this? Is there a better way?
PS - I am just getting started so detailed answers or links to tutorials as to how to implement it would be much appreciated.
Thanks.
Yes you can easily do this with Servlets and some Json Libs for Marshalling /unmarshalling the Json Object to Java Object.
You can make use of Json libs like
Jackson ,
Gson etc
But you must know that REST application doesnt end with just handling the request and response , but it needs to take care of other non-functional requirements like
Authentication
Authorization
Security etc
Building this from a scratch from a Servlet is overkill and waste of time when there are ready made frameworks that these things for you
My favorite is Spring MVC 3.0
Check their project site for more details
Just to show you how easy to set up one in Spring MVC , check this below tutorial
Spring 3 REST Tutorial
Pls rate the post if it helps , Cheers.
If you want to go with Java, I suggest that you take a look at JAX-RS... And since REST is a complex topic, here is a url with tons of informations on it. http://code.google.com/p/implementing-rest/
As a complete beginner, I believe the best way to implement a (nearly) RESTful API without having to read a lot is simply to implement the API just using HTML pages and HTML forms with the back-end processing to handle them.
The rules are:
Use <a> tags to provide links to related resources. (navigation)
Use <form> tags to initiate any kind of processing operation on the server. (actions)
You can then make it properly RESTful by using progressive enhancement to add Javascript AJAX requests that perform PUT, PATCH, and DELETE instead of using POST for those three (of course, keeping POST for creating resources where the client doesn't know the resultant URI).
You can then click around and test the API in a web browser! Tools like Selenium can automate this.
If you need to provide JSON, this can be added after the API has been designed and tested, although libraries exist to process HTML or XHTML responses too, so JSON isn't necessarily required for machine readability.
if you are using php with symfony try:https://github.com/FriendsOfSymfony/FOSRestBundle this lets you create a real REST full servicer very quick.
Vogella made my day very easy when i started Web services with an super example here with eclipse screen shots ..Have a look here.
Is there a general Cocoa or Cocoa Touch library for interacting with any web service API, or one which can be used as a basis for creating my own library for a web service? For example, I could add some details about how to interact with the Vimeo API (how to verify user details, what URLs to call). I'm not sure how this would work in reality.
If not, can anyone suggest an web service library which I could alter to change the API calls? It would need to be fairly simple (a small API) and easy to adapt. An example is this Cocoa library for Twitter (although it would probably be too complicated to adapt). Would it be easier just to code it up from scratch?
I don't think there is a library that will automagically work with any web API. In fact I don't even think it's possible to write such a library, since you can define your web API any way you want to. That library would have to be pretty smart in order to figure out how to use an arbitrary API.
I think the closest you'll get is something like ASIHTTPRequest, which is a great library for interacting with web services. If you add a JSON and/or XML parser you'll have everything you need to interact with almost any web API.
Found another library for interacting with RESTful web services. It's called RestKit. From their description:
RestKit is a Cocoa framework for interacting with RESTful web services in Objective C on iOS and Mac OS X. It provides a set of primitives for interacting with web services wrapping GET, POST, PUT and DELETE HTTP verbs behind a clean, simple interface. RestKit also provides a system for modeling remote resources by mapping them from JSON (or XML) payloads back into local domain objects. Object mapping functions with normal NSObject derived classes with properties. There is also an object mapping implementation included that provides a Core Data backed store for persisting objects loaded from the web.
I have been reading about REST and SOAP, and understand why implementing REST can be beneficial over using a SOAP protocol. However, I still don't understand why there isn't the "WSDL" equivalent in the REST world. I have seen posts saying there is "no need" for the WSDL or that it would be redundant In the REST world, but I don't understand why. Isn't it always useful to programmatically bind to a definition and create proxy classes instead of manually coding? I don't mean to get into a philosophical debate, just looking for the reason there is no WSDL in REST, or why it is not needed. Thanks.
The Web Application Description Language (WADL) is basically the equivalent to WSDL for RESTful services but there's been an ongoing controversy whether something like this is needed at all.
Joe Gregorio has written a nice article about that topic which is worth a read.
WSDL describes service endpoints. REST clients should not be coupled to server endpoints (i.e. should not be aware of in URLs in advance). REST clients are coupled on the media-types that are transfered between the client and server.
It may make sense to auto generate classes on the client to wrap around the returned media-types. However, as soon as you start to create proxy classes around the service interactions you start to obscure the HTTP interactions and risk degenerating back towards a RPC model.
RSDL aims to turn rest like a hypermedia, in other words, it has more information than a service descriptor like WSDL or WADL. For example, it has the information about navigation, like hypertext and hyperlinks.
For example, given a current resource, you have a set os links to another resources related.
However, i didn't find Rest Clients that supports this format or Rest Server Solutions with a feature to auto generate it.
I think there is a long way for a conclusion about it. See the HTML long story and W3C vs Browsers lol.
For more details about Rest like Hypermedia look it: http://en.wikipedia.org/wiki/HATEOAS
Note : Roy Fielding has been criticizing these tendencies in Rest Apis without the hypermidia approach: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
My Conclusion : Now a Days, WADL is more common that Rest and Integration Frameworks like Camel CXF already supports WADL ( generate and consume ), because it is similar to WSDL, therefore most easy to understand in this migration process ( SOAP to REST ).
Let's see the next chapters ;)
Isn't it always useful to programmatically bind to a definition and
create proxy classes instead of manually coding?
Agree wholeheartedly, this is why I use Swagger.io
Swagger is a powerful open source framework backed by a large
ecosystem of tools that helps you design, build, document, and consume
your RESTful APIs.
So basically I use Swagger to describe my models, endpoints, etc, and then I use other tools like swagger-codegen to generate the proxy classes instead of manually coding it.
See also: RAML
There is an RSDL (restful service description language) which is equivalent to WSDL. The URL below describes its practice http://en.wikipedia.org/wiki/HATEOAS and http://en.wikipedia.org/wiki/RSDL.
The problem is that we have lots of tool to generate code from wsdl to java, or reverse.
But I didn't find any tool to generate code from RSDL.
WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate
However, REST uses the network protocol by using HTTP verbs and the URI to represent an objects state.
WSDLs tell you at this place, if you send this message, you'll perform this action and get this format back as a result.
In REST, if I wanted to create a new profile I would use the verb POST with a JSON body or http server variables describing my profile to the URL /profile
POST should return a server-side generated ID, using the status code 201 CREATED and the header Location: *new_profile_id* (for example 12345)
I can then perform updates changing the state of /profile/12345 using the HTTP verb POST, say to change my email addresss or phone number. Obviously changing the state of the remote object.
GET would return the current status of the /profile/12345
PUT is usually used for client-side generated ID
DELETE, obvious
HEAD, gets the status without returning the body.
With REST it should be self-documenting through a well designed API and thus easier to use.
This is a great article on REST. It really help me understand it too.
WSDL 2.0 specification has added support for REST web services too. Best of both worlds scenario. Problem is WSDL 2.0 is not widely supported by most tools out there yet. WSDL 2.0 is W3C recommended, WSDL1.1 is not W3C recommended but widely supported by tools and developers.
Ref:
http://www.ibm.com/developerworks/library/ws-restwsdl/
The Web Application Description Language (WADL) is an XML vocabulary used to describe RESTful web services.
As with WSDL, a generic client can load a WADL file and be immediately equipped to access the full functionality of the corresponding web service.
Since RESTful services have simpler interfaces, WADL is not nearly as necessary to these services as WSDL is to RPC-style SOAP services.
I'm thinking about creating an application for the iPhone and Android that will need to access a common backend to retrieve account information. Can both access a web service over https? What other way would allow me to have one interface to the backend that is accessible by both?
They both work over http and https which is a common enough protocol. I would suggest you go with a RESTful web service so you expose your service via URI's like http://www.myservice.com/weather/zip/98007 which would return an XML blob that can be parsed by the client.
if you are starting from nothing, i'd definitely go with RESTful service that returns/accepts JSON... there are plenty of libraries for both platforms that will accept JSON and turn it into arrays and dictionaries.
I'd recommend using a RESTful web service backend, which is all standard HTTP and/or HTTPS. If you can use Ruby on Rails, its default scaffolding will get you about 99% of the way there and for the iPhone there is an open source project called ObjectiveResource that will automate your communication with this Rails backend. I haven't investigated yet what options are available on Android but since it is all simple HTTP it should be straightforward. I am not the maintainer of ObjectiveResource but I have contributed some code. You can check it out here:
http://iphoneonrails.com
One good approach I have seen used with other services is to write the backend in such a way that it can feed data back in different types - for Android an XML response is best, but for the iPhone sending back plist data is preferred (though it can also work with XML if required). In both cases it's easier to simply POST updates back to the server than to wrap an update in XML.
Both platforms should be able to use whatever form of authentication you wish to use, the iPhone I know supports all methods of HTTP authentication.