why we are adding headers in interceptors?I have gone through several websites and I can't understand
Adding headers is not the purpose of interceptors. Header manipulation is just one of the things you can do in interceptors IF the need arises. It's up to you to use them if/when you need to.
Examples I've used interceptors for:
Adding client-side caching functionality for certain specific service calls.
Faking a back-end call for a demo application such that the http call does not go through with the full call to the server.
The documentation provides an explanation and a few examples including ensuring that requests are made via HTTPS, some help with authentication settings, and manipulating request bodies.
Related
I am developing a single page app running in desktop browser, tablet browser and maybe phone browser. I am return only JSON from my backend wether it is ASP.NET MVC or Web API.
When I think of Web API or read about it I always hear the words REST/RESTfull. Independently from what REST is I like some features about Web API which I have not in MVC (by default but maybe it can be implemented somehow but I dont want that extra effort...)
Return HttpStatus codes like 200 for GET or 201 when the Ressource is created. My single page app knows and reacts on this codes.
Return DTOs directly in the controller and c# classes are automatically serialized to json. With MVC this is not a one-liner. Not dealing with ActionResults.
Web API is very much designed about 'cool' urls/routing I will also have deep/complex routing on my client.
My Web API endpoints are just 'ajax callbacks' I do not need REST things like include a self.link in every retrieved ressource etc...
Of course I do not create/modify ressources on a Get request. But I already have been used to this style when I was doing MVC. So I like and will do many REST styles but not because of REST itself rather its common practice.
Should I really design great restfull API`s to use the Web API ? I do not know what is Microsofts recommendation about the Web API or wether they have really a guideline about it...
In my experience Web API has often been a great help, and rarely a hindrance. If you do it "their way," it saves you a lot of ugly work around serialization/routing/binding. If you don't want to do it "their way," you don't have to. You can extend the routing engine. You can implement your own serialization. You can return raw JSON where you see fit. Nothing in Web API forces you to follow the REST concept to a T (trust me I have seen this in action). I haven't heard this complaint before from anyone who has used it - I would suggest you give it a try and see just how far off it really is.
REST is not at all required to use Web API. In fact, it is quite easy to turn on and use session management as well.
In fact, while RESTful approaches have some real advantages, I wouldn't recommend going 100% RESTful. It is simply not possible to make them fully secure without using a third-party authentication provider. We built a fully RESTful prototype and explored many different mechanisms to secure the site. In the end, though, every one had one vulnerability or another (it helps to have a CISSP on staff). So I talked to one of the top security experts at Norton and he agreed that, yes, there is always a way to exploit a fully RESTful, standalone app. Symantec is apparently building a "wrapper" technology that gets around this but it was easier to either go with a third-party authentication provider or just go back to MS-based security using session cookies.
I want to build a Rails application that expose a RESTful web service used by a mobile application. I wanna create something maintainable and scalable, but I'm a little bit confused about best practises to achieve a good result.
First things first, API versioning. Over time my APIs will grow up and I want to keep them as smooth as possible. I've read this post: Best practices for API versioning? and I completely agree with it.
An excerpt of my routing strategy is:
/api/v1/ .. all sorts of controllers (api v1) ...
/api/v2/ .. (api v2) ..
/api/ .. controllers of the latest mainstream API
As a development strategy, I take advantage of JSON data formats, also to create new resources.
Another important aspect I'm afraid of is security: I cannot generate an authenticity token from the mobile APP, so I'm wondering how to protect the Rails API controllers.
Should I use standard HTTP authentication? Are there better ways to do that?
Last but not least, I'm trying to improve overall performances: remove unnecessary rack middlewares, inherit from ActionController::Metal and get rid of ActiveResource. Should I consider some pitfalls?
Any suggestion to build such a RESTful application will be appreciated.
You seems to be on right track, there are few things I want to mention:
Decide the input and output format. JSON is a faster choice but XML provides schema validation and more control. Chose depending on your need.
Use simple HTTP Basic authentication for security to start with. If you want more control, then introduces token based authentication such as OAUTH.
Make sure you use the plurals for the REST entities in URL. As plurals are good for a single or multiple entries fetch.
Decide about the synchronous and asynchronous nature of REST APIs. If an operation takes too long then make it asynchronous. Return a ref URL to user for polling as part of 202 Accepted response.
Hope it helps!
So we currently have a website that was created using Django. Now, we would like to create a native iOS app that uses the same backend, so we don't have to re-code the whole thing. From my understanding, there are two alternative routes:
1) Call directly Django URLs, which then calls a function. Within that function, create a HTTPResponse, with encoded JSON data and send that back.
2) Create a REST Service from the Django server with something like Tastypie. However, aside from doing straight-forward GET calls to an object, I don't see how we can call custom functions in our Django Models from TastyPie. Can we even do that?
I find it surprising that there is not a lot of information about consuming a web service from iOS with existing backends like Django or RoR. For example, I know that instagram uses Django, but how do they communicate from iOS to their servers?!
Thanks a lot!
I am currently working on an iOS app for iPhone, with Django / Tastypie in the backend. We do both 1 and 2. The resources are offered REST-style (after auth) via Tastypie, and any custom function calls (for example, creating a new user) are handled by views.py at various REST endpoints, which returns JSON.
When you can you should try to use a common way of doing something instead of reinventing the wheel. Given that, REST is a standard style of software architecture for distributed systems and it works very well when you work with entities/objects.
If you have an API where you interact with entities, it is recommended to use REST interfaces. On python you have Tastypie or the newer Django Rest Framework that does almost all the work. As you propose in 2)
If you have an API where you interact with services, like a login, then you should build an RPC service, basically a function with remote access as you explain on 1).
Normally you will need both ways on a robust application. And YES, it is possible to do that. I agree with #sampson-chen, we are doing the same. We have a REST interface with tastypie, and other methods are done with custom RPC services.
The performance in our case is still good, but mostly depends on the methods you call inside your services, for example, a DB query. You have a lot of ways to improve speed, for example using Celery to queue heavy jobs.
Hope it helps.
REST APIs, while very useful, limit you to GET, POST, PUT, DELETE actions, which are performed upon resources. This can make it difficult to express other action types, such as sending an email. There are a few ways I've found to handle this within django/tastypie:
Issue a PUT/PATCH request on an existing resource, setting a flag that lets your backend know to trigger an action. Detecting if a flag was set can be done inside post_save signal handlers (use django-model-utils FieldTracker to see if a field was changed from False to True); this also helps make sure your application logic works the same outside your REST API (such as changes via the admin site, a celery task, an HTML based view, or the Python shell).
Create a non-ORM Resource (e.g. /api/v1/email/) and override the post_list() method, calling your function there.
As mentioned elsewhere, create a subordinate resource (/api/v1/myresource/send/).
We're putting together a series of services using ASP.NET Web API. One proposal is to implement a "choreography" type design pattern where all clients connect to one endpoint and get routed based on the content of the GET and POST bodies. Another proposal is to just call each service directly.
What are the benefits of using a choreography-type design pattern?
Personally, I prefer one URL for all my services. It seems simpler but a single endpoint for simplicity isn't a valid argument.
Update -
I'm open to using headers for the routing portion. We're at "conceptual level" design at the moment and I guess I didn't think about using headers before posting. The body will be JSON. I am proposing this be implemented using ASP.NET Web API 4. Based on the header, the choreographer will route to the appropriate endpoint for processing.
If you are going to route only based on the content of the GET and POST bodies then I would say that you would be reinventing SOAP which is now considered heavyweight and legacy.
If you include the HTTP headers in this decision then you will be more RESTFul which is a good thing. You might also checkout the Web API which might help you with this design.
I have done the backend part of a project in java (Maven) and use a Restful design.
The structur in java/(Maven) is:
1) domainlayer
2) datalayer
3) webservicelayer(client)
And the frontend part will be done in groovy/grails.
The only parts I'm doing to write in grails are: controllers and views.
The structur is:
1)Controllers
2) views
My question is how we can link them two parts together. Since Restful part is written in Maven and creates a war file.
How can I get frontend connected to the backend?
One of the really great features of grails is the GORM, so I'm not sure why you'd want to skip that part. Typically you'd only use a controller if you needed to get some data from a backend and then forward to a view. In your case you've already written the backend, so you could actually just do ajax pages that call the REST interface, and that might be all you need. If that's the case you hardly need grails; you can just put the static pages under your project's src/main/webapp folder and you're done. On the other hand, if you want to use grails for the GSP pages, you can make the controllers be do-nothing (so it's just specifying routes really) and have the view be GSP pages that make ajax calls. If you're going to do this be sure to check out jquery since it has really nice ajax support.
REST is talking HTTP so your Grails application will be the client of that. Although, it is a bit wasteful to have Grails in the middle, you can probably design your front-end in JS and do it all in the browser bypassing Grails all-together.
If you are bent on going the Grails way, you will need an HTTP Client (commons HTTP client is a pretty good one) and then on the receiving end you will be able to parse responses, this is where Grails will actually be useful. grails.converters has a nice method for you
JSON.parse(responseText)
It is entirely possible there is a better way of either parsing or doing client HTTP. For example, grails' functional-test plugin wraps HTTP library so you have a bit of a groovy feel for that communication. You might want to look at how it is done there. Not sure if anything better can be done with regards to JSON parsing.
HTH,
Alex.