Lets have this explained by example: Can we have a website (A) dedicated for creating access tokens and handing it to another website (B) to access its endpoints? is there anything like that or a practice for having such thing?
There are similar patterns used for this such as api gateways that can be used to monitor and restrict access to endpoint services.
A common approach could be a micro-service pattern where a website has many endpoints that are mainly designed to support the website functionality (standard behaviour). Another website or other applications eg companion mobile apps may also point to endpoints of the first website for authentication purposes and actual data.
Depending on complexity, it may also me useful to split up the endpoints to separate functional components - eg solution that only performs authentication, another providing data for crud, another services another application and etc.
Essentially there are many patterns but this approach is fairly common when a eco-system of related applications communicate together.
Related
(Please let me know if this question belongs to a different stackexchage site)
I have a use case where the clients of my service have to call some APIs exposed in the service. The API specification model being used allows for auto-generation of client bindings for different languages.
I need to provide an enhanced functionality around some of the APIs and that custom code sits around the calls to the API. Instead of expecting every client to write this code on their own, I would like to provide this as a wrapper around the auto-generated client library. I understand that this needs to be done for different languages to be supported (the list if 2-3 in my case).
In general, is this a good choice to make? Are there any other alternatives?
Please let me know if more details are needed.
Generating clients from some kind of API Definition (like OpenAPI) and shipping it with other code is a very common pattern and i've used and created such clients in the past. For the consumers of your API this has some clear advantages: He doesn't have to generate the client (depending on the used technologies is sometimes painful), he benefits from the maintenance done by the provider (and others), and uses the official way to interact with the API.
In such a client there are three main packages which should separated and independent from each other:
The generated client
Code which eases the usage of the generated client
Other Code (i.e. utilities that abstract or simplify common interactions, provide domain logic required on the client side etc)
If these are separated it is very easy for a consumer to pick the pieces he wants to use.
The main disadvantage is that you have to implement and maintain multiple clients for your API. Depending on the size of your API, the supported platforms and environments the clients are used in, this can be a very elaborate task. Also keep in mind that providing a decent client library requires a good understanding of the target platforms and environments. Otherwise your client library might not be accepted by other developers.
In general generated code if often not that "natural" and "nice". For example the generated identifiers might not follow the conventions of the platform or it requires the usage of over complicated constructs like factories to create a simple object. Often the generators can be tweaked, but this adds to the required effort.
All these efforts often add up, so that even big API Providers struggle to provide good client libraries for many platforms.
There are two alternatives:
Only provide a API Definition
Handcraft a client
The first alternative gives the consumer the freedom to choose the way he wants to use your API. But given a good API Definition (which is hard to write), it is relatively easy to do so. In this case it is not possible to provide some additional code to the client. But in general you should aim for dumb clients and avoid clients to perform business logic.
A handcrafted client is best suited if you aim for a limited number of platforms on which you want to provide the best possible experience for the consumers. Further you can implement all kinds of other stuff. But even for a single platform this might be a huge effort.
I need the opinion of the person who has used/uses 'Restier' in the production.
I see some issues - security is disabled by default - all data can be read by the user who is not even authorized on site. Even if we plan to restrict some data - you can not remove one column from the table - only all columns will be visible to the client.
And the last - all business-logic moved to browser javascript - which is not good. If we need to perform a complex operation (which must be in a single transaction) - it is not possible.
My opinion - 'Restier' is designed for very simple RESTful projects - such as the address book, todo list etc. If you develop the big commercial application - that operate complex data scheme and operate money transactions - you should avoid using 'Restier' in a project.
Any thoughts appreciated.
REST is an arquitectural style for Web Services.
OData is a standard that describes a good technology independent implementation of REST.
RESTier is a library that implements OData V4.
The complexity of your domain must be in your Domain and Application Layer.
You can use RESTier to expose your domain functionality as a WebService the way you like. You could expose your entities only for Read operations and expose your use cases (Application Layer) as OData Actions and Functions which can the be consumed by any kind of client (iOS, Android, Web Client such as Asp.Net Mvc, Wpf , any JavaScript Frontend etc.)
If you have a complex domain I would suggest you to investigate Domain Driven Design.
Now to your questions...
Regarding security you can implement all the goodness of Asp.Net in Restier.
Regarding data shaping you never expose your domain entities directly through the Web Service. I would suggest to implement factories that convert back and forth between for example Customer (domain entity which represents the business logic) and CustomerDto (simple Data Transfer Object) . With this you can shape your data to be exposed the way you require.
Having the business logic in the Front End (UI Layer), as you mentioned, is considered an anti pattern (smart UI anti pattern) if you have big domain complexity. (For simple CRUD apps is ok). Restier does not push you in this direction. It is a matter of how you architect your solution.
Hope this helps you.
I am pretty new to stuff related to server and backend services and I want to develop a mobile app with a backend part. I want this backend to serve an ios app, an android app as well as a website.
My concerns today are how does the frontend part communicate with the backend part :
does it work the same way a website works ? (Http request to the server ?)
how does happen the exchange of datas between the frontend and the backend ?
which are the common solutions to my problem ?
is there an efficient way to desing this backend to serve mobile apps as well as a website ?
is parse (https://parse.com/) a good starting point ?
Thanks
Looking at your questions in turn:
does it work the same way a website works ? (Http request to the server ?)
There are many options, but probably the most common, or fashionable, at the moment is to use a RESTFUL interface:
http://en.wikipedia.org/wiki/Representational_state_transfer
Previously, a SOAP based web service might have been the most common choice:
http://en.wikipedia.org/wiki/SOAP
See here for some discussion on why you might use REST rather than the SOAP now:
Why would one use REST instead of SOAP based services?
how does happen the exchange of datas between the frontend and the backend ?
Assuming REST, HTTP is used to transport messages and application data is typically included in XML or JSON forms
which are the common solutions to my problem ?
I think this is covered by the other parts of the question/answer.
is there an efficient way to desing this backend to serve mobile apps as well as a website ?
Thats very dependent on your particular server application, especially its size and architecture. If the server application is broken down into components or parts, and the parts that generate the 'views' or the 'HTML' pages for the web app are distinct and well separated from the 'backend' parts of your server application, AND your application is of a type that the functionality is largely the same whether the end user is using a web site or a mobile and it is just the way the view are generated for the different devices that differs, then an efficient design would be one that keeps as much of the backend common as possible. If the use of the application is very different when used by a mobile client this may not make sense. More generally, an efficient design would keep as much functionality as possible common between the Mobile and Web applications.
It would definitely be worth becoming familiar with the 'Model View Controller' architectural pattern as most of the server side frameworks, as well as many of the Javascript Web client frameworks and even the iOS and (to a lesser extent) Android frameworks use these concepts:
http://en.wikipedia.org/wiki/Model–view–controller
One important considerations whether you need 'push' or notification like functionality on your mobile app. If so you may want to look at some of the common solutions to understand if they meet your needs - probably easiest to start with Apple and Google's offerings to get an understanding, but there are lots of other solutions available also:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
http://developer.android.com/google/gcm/index.html
is parse (https://parse.com/) a good starting point ?
I am not familiar with this service but you might be better looking at a simple REST based approach first and see if it meets your needs.
To answer your question
is parse (https://parse.com/) a good starting point ?
Yes it is.
But I would recommend you to read well on topics such as
REST services
RESTful services vs SOAP - a good article
REST/JSON vs REST/JSON
Services such as parse are called Mobile Backend as a Service (MBaaS).They are ideal to quickly create web services for mobile developers who have little experience with backend development.
A quick search on google on 'MBaaS' will return many services similar to parse and most offer free developer accounts. (With a certain Number of free API calls per second/app)
I have used Apigee similarly & the open source equivalent is Usergrid.
These services will provide a GUI for the developer to create & deploy services and the services are immediately available.
Separate test & production end points will be available.
In addition to basic CRUD operations, these services will also enable easy social network integration, caching & analytics (Depends on service provider)
Features such as security, scalability are built in by the MBaaS provider(Like Parse).
I have a scenario where I have multiple websites using a commnon dll for authentication and general user detail fetching.
I now need to update the common dll with a slightly different login logic and it means I'll need to push this new dll into every website and do a release process for each.
I'm wondering whether it's better to host the common authentication methods in a webservice of some sort then have the websites call that internally. Would it be an internal web service? ajax callbacks from an server side only website? Or stick with the dll method to ensure code changes doesn't break the sites?
Are there any security concerns when not using a dll for this kind of task?
Using a webservice seems a good way to do that. I will cause less memory usage and can be updated independantly from the wesites (if ever needed).
You could go for a WCF services (with dual tcp?) maybe.
Both approaches work in my opinion, but there are significant differences between them that we should keep in mind.
First of all, all of this depends also on the language you are using, because sometimes the best theoretical answer is not always easily implemented in each and every language, making it practical unusable.
So, with this in mind, the best way for me is to have an internal web service, who deals with all requests regarding this "authentication and general user detail module", assuming that all websites use the same DB (or data layer) (otherwise, you will need to create a web service for each one and it's another completely different story). This approach will give you flexibility and maintainability. You could use direct ajax requests to this web service, or make the calls from you website server, and them reply to the browser already with that information. (this second option is more time consuming but much more secure, and if it is a real internal web service (ie hosted on the same machine, the lag will not be noticeable)).
The dll approach should if you need to apply the same business logic to different services. In practical terms: you have two completely separated web sites, that use the same kind of authentication logic. Keep in mind that using this approach to websites that use the same data layer, will force you most of the times to have "deprecated ways" working together with the new implementations, while you are updating the dll on all websites.
Regards,
I'm going to build an API for a web app and I'm interested in what people can suggest as good practices.
I'm already planning to make it versioned (version 1 can only control certain aspects of the system, version 2 could control more, but this may need a change in the way authentication is performed that would be incompatible with version 1), and the authentication will be distinct from the standard username/password people use to log in (if someone does use a malicious tool it won't open them up to full impersonation, just whatever the api allows).
Does anyone have further ideas, or examples of sites with particularly good APIs you have used?
Read the RESTful Web Services book, which give you a good overview of how to use REST in practice, and get to up to speed quickly enough to get started now, with some confidence. This is more useful than just looking at an existing API, because it also discusses design choices and trade-offs.
1) Bake the version number directly into the URL rather than passing it as a parameter, since that gives you complete freedom to change the organization of your API namespace with each version bump.
2) Keep your URL rewriting rules (if any) as simple/lean as possible (but no simpler), while making your URLs as beautiful as possible (but no more).
3) Always look for the best HTTP status code you can find for each response (and don't forget about 202 and 207, for example).
4) Implement fascist parameter validation logic, and informative error messages.
5) Use HTTP request headers where appropriate instead of parameters (like Accept, for example, to allow clients to specify the desired data format of the response).
6) Organize your "nouns" in such a way that the URLs used by different client audiences are separated near the "root" of your URL tree (this makes it easier to enforce different authentication mechanisms for those different audiences if needed, or even map different portions of your URL tree to different servers).
7) If you're serving regular web pages off the same domain as your APIs and use the same authentication credentials, require an X-Requested-With header in your API requests so as to avoid XSRF vulnerabiities.
I would take a look at proven APIs:
YouTube API
Twitter API
There's a lot of argument about whether these APIs are "good" but I think their success is demonstrated, and they're all easy to use.
Use REST.
RESTful web services architecture is easy to implement and uses the strengths and semantics of HTTP for what they were intended. It's resource-oriented, just like the web itself.
Amazon Web Services, Google and many others offer REST APIs to interact with their products.
Use REST.
Read up on standards for APIs, or copy the ideas from one of the popular ones.
Be careful when authenticating users.
Start very very simple.
Build a site that uses your API (even if it's not useful) to check things work. Perhaps you could build a mobile version of the site or something that forces you to use the API in a lot of depth.