I am building an application in loopback and wondering how to build a service layer with an API which is not related to any model. Here is my scenario.
I have a two models User, Game, UserGames. UserGames is a many-to-many relation and stores the score of users in different games. I want to provide an API for weeklyLeaderboard but I don't want it to be a Remote Method for any of the my models as it doesn't fit the RESTful API guidelines.
The only way I can find to implement right now is to create a service common/service/weeklyLeaderboard.js and a route in server/boot/routes.js which accesses this service. In that case, I would have to re-arrange the middlewares in my middleware.json to have non remote-method end-points treated in the same way as remote methods and have access to the currentContext.
Is there a better way to implement APIs which are not related to a specific model but access several data-access and business objects.
Disclaimer: I am a co-author and an active maintainer of LoopBack.
In our recently released LoopBack version 4, we have decoupled REST APIs from the database access. REST APIs are implemented by Controller classes, data structures are described by Models and database is accessed via Repositories. This makes it easy to write a service layer that's decoupled from data-access details.
In LoopBack 3, I recommend to create a new model (e.g. Leaderboard) and treat it as a controller. There are two tricks needed to make it work:
Inherit from Model, not the default PersistedModel. That way your controller-like model starts empty, with no (built-in) remote methods.
Don't attach your controller-like model to any datasource. In server/model-config.json, set the dataSource entry of your new model to null.
Then you can define your weeklyLeaderboard endpoint as a regular remote method and get all benefits offered by LoopBack, e.g. your new endpoint will be included in the generated Swagger spec and testable via API Explorer.
Related
I have a requirement to build a service endpoint to provide specific Sitecore 8.0 items (containing a given field value in a given branch of the content tree) to requesting mobile app clients. Encapsulating this logic (and perhaps some other calculations, etc) means the out-of-the-box API is not suitable.
I'd like to mimic an existing SOAP service exposed by another CMS, however I'm not above using a modified version of the RESTful itemWebApi if it confers greater code reusability or upgrade-safety.
Based on my research thusfar, it would appear my options are to build a custom handler, a completely separate asmx service (ala this approach), or to build a custom controller (similar to this custom Web API controller method).
Overriding or replacing the default pipeline processors for the itemWebApi does not seem viable, as I don't want to replace/modify the OOB API if I can avoid it.
Has anyone with the same type of requirement for Sitecore 8 found a better approach?
The approach I chose was to create a separate service "router" developed using the adapter pattern to be consumed by our mobile app clients. The router in turn calls the Sitecore ItemWebApi.
This fit my needs the best as it is completely decoupled from the Sitecore application and the client can be modified if necessary without impacting the endpoint.
It would also be worth looking to EntityService within Sitecore.Services.Client in Sitecore 8. Its a Web API based service but has more flexibility over the standard Sitecore Item Web API because you can define your model and the business logic yourself.
I can see you have mention my other blog post on adding a custom Web API controller. Enitity Service is different, it's a framework by Sitecore to achieve a standard way of creating custom web service for Sitecore.
I have written a blog post on EntityService. It has both a Javascript and standard rest based API to communicate with the service too.
http://mikerobbins.co.uk/2015/01/06/entityservice-sitecore-service-client/
Example Application here: https://github.com/sobek1985/EntityServiceDemo
And a few more posts on advanced features in Entity Service: http://mikerobbins.co.uk/category/sitecore/sitecore-service-client/
my requirement is to sync third party e-commerce systems(IFS) products into sitecore. Is there a way that i can extend sitecore web service with new method where i can get the products and create them in sitecore? or is there a better way to do this.
I want to create that as sitecore module, so that we can install it on any sitecore website we have to integrate with that e-commerce systems(IFS).
http://yourhost/sitecore/shell/webservice/service.asmx
Any suggestions will be appreciated.
You could potentially use the Item Web API (PDF link) that Sitecore comes with, or even roll your own web service that you write and call the native Sitecore API. If you roll your own, you could expose it as a WCF service, or a Web API or any other approach. The service you found and referenced is quite old and not really designed to be extended.
Another approach to what you are trying to do (merge/integration another system into Sitecore) would be to write your own item data provider. Here are some links on that topic:
Integrating External Data Sources
An introduction to Sitecore data providers
The Black Art of Sitecore Custom Data Providers
Please take a look on the Sitecore Commerce Connect product. It has been designed for such kind of tasks, see chapter 2.1.7 Product Synchronization:
Product Synchronization
Connect has its own product data model and a
Product Synchronization service layer for exchanging product data with
one or more external systems. The responsibility of the Product
Synchronization service layer is to manage two-way synchronization of
essential product data. The goal is to synchronize only the data that
is needed to satisfy the most common e-commerce scenarios. In
particular cases, the model can be extended. For more information on
the default scenarios that are supported, see the developer guide.
You should consider using a Custom Data Provider, it's for fit for the task at hand and will allow you to also manage the external data in a similar way to native Sitecore Items, inc caching and publishing.
There is more information in the Integrating External Data
with Sitecore document on SDN and and Nick Wesselmans article on The Black Art of Sitecore Custom Data Providers is a go to reference.
Also these blog posts provide more details on read-only data providers, which is most likely what you will want to use for external data:
A simple read-only Sitecore data provider
Custom data providers in Sitecore
I want to build an e-commerce application using JSF 2.0. I saw some examples (including the ones that come bundled with NetBeans). In those examples data was stored in some sort of database and was retrieved and queried using SQL. In those examples there was some sort of persistent object in the application. What I want to do is retrieve data from a Restful Web Service and so I will not use SQL at all. My question is: Do I need to include a model section (MVC pattern) in my application having persistent objects or should I just use beans which will directly connect with the web service? How does such an application generally work?
Your REST service would provide some data (JSON, XML), probably it would be handy to map these data to model classes on JSF application side. So in your JSF bean you would connect REST service, map data obtained from it to model classes and then call some bussines logic (that use model classes).
Obviously if the REST service returns single number or string there is no use to create another class just for the sake of architecture. Similarly if you bussiness logic is very simple, it is better to do everything in JSF managed bean class.
I need to develop/design Coldfusion Web Service which uses few object calls and functions.
What is good source of samples to develop in terms of OOP?
What is best way to secure the web service?
how to authenticate external/internal users, any sample?
FYI, This web service is going to be used by multiple department.
thanks
A
OOP examples are all over the web. I don't have any handy, so I'll skip that part, and go straight to authentication and security.
First, authentication. There are several possible answers depending on what kind of users you are authenticating. For example, if you are authenticating users connnecting via a 3rd parth tool -- like a desktop or phone app posting to Twitter -- I would say that OAuth is a good solution. There is a good library for both publishing and consuming OAuth integrations at oauth.riaforge.com. If you are looking for someting lighter weight, we used a simple token creation scheme for a webservice that was only consumed by partner services. Basically, the partner service sends what amounts to a username and password pair, a token is created with a "last used" timestamp, and every time the webservice interacts after that, we do a check against the token store.
Security is, similarly, very dependent on your end goals. However, there are a few basic principles I've always tried to follow. First, build your basic CFCs as you normally would for constructing your objects. Entry points should be public, helper functions private, etc. This includes building an object to handle whatever authntication model you choose. On top of that, build your public API. These should all simply be access functions. They are called by outside applications, call the security object, then call the appropriate objects and methods to achieve the goal of the call. This way, you never have to bake the security layer into your base functionality calls, but you also have an easy way to include security. Remember, a single API call does not have to reflect a single base call -- you can build more complex routines if needed.
So, to recap.
Authentication
OAuth
Temporary Token Generation
Security
private/public (not remote) base layer
private/public (not remote) authentication layer
remote API layer
A friend wants to consume my ASP.NET MVC 2 application in a similar fashion as adding a web reference to it, accessing my functions, and using my model objects from a .Net web form from a separate website.
Any links out there that could explain how to "dress" my MVC responses so that his server to server consumption would be similar in experience to a web service?
I suggested using System.Net.WebClient to pull the results in to a variable then deserialize the JSON result, but maybe there's a better approach out there?
I'd suggest that you consider an API controller or a separate API application depending on the load you expect from people consuming data from your application. A separate API application will allow you to move it off your application servers if needed.
Rarely, will you find that the data that you would provide via an API is a one-to-one match with what your views need to be rendered. Behind the scenes you could abstract the data generation so that your API and your application controllers reuse the same code to get at the data, but the front-end of the API would understand how to negotiate security (from an API perspective) and present data that is easily consumed by a program. Moreover, you won't find that you're creating extra controllers and methods in your application just to provide some data that will never be used in a particular view.
You could use MVC or WCF for the API and JSON or XML as the payload format. If you use WCF, you get the benefit that he really can simply add a service reference to connect to it without you having to build a WSDL file/action.
From another's advice, Phil Haack added this to MVC 2 Futures. Add the DLL reference to the Application Start, and bingo. It uses a validator.