I'm building an API onto a web app, and I have a few questions on how it should be set up.
Certain records cannot be created through the web app itself, but the API can have full control of not only creating, but other web-app functionality as well.
Let's say I have 3 rails objects: User has_one Business has_many Ratings
In the web app, the user has full CRUD control over Users and Businesses, but only RUD control for the Ratings (no create).
In the API, there is full CRUD control of all three objects.
So, with this being said, how should I structure my files? At first glance, one would think that I would create normal controllers for all three objects and just restrict the "Create" event in receipts_controller.rb for JSON access (API). However, if I use namespaces for my API ( myapp.com/api/v1/receipt.json ), wouldn't I need a separate controller for my receipt object?
While writing this, I got the idea to just namespace the API like normal and have the /api/v1/receipts_controller.rb file extend the normal /receipts_controller.rb -- would this be the correct approach?
Obviously I do not want to have the web-app and API running off of different controllers, which is why I'm seeking some advice on the matter.
Not sure if I understood your explanation. Here is my 2cents. I prefer to have separate controllers for API and he Web App.
For couple of reasons:
when you start to releasing the new versions you don't want to change the web app controller also you don't want to have too many if conditions. This is pure evil. All you need is making the ~/v2/~ and put all the logics there.
Skinny Controller is the key, mixing both API and Web App Controller makes it harder to debug your controller and you might end up too many methods
Having different controller for API gives you the ability to enforce different security policy on it and leave your web app alone.
Related
I am trying to integrate our third party application with NetSuite. I want to be able to import sales invoice details generated from our third party system (which uses REST API) into the NetSuite invoice form.
The frequency of import is not too crucial- an immediate import will be ideal, but sending data once a day is fine as well.
I want to know what I have to use to do this API integration - SuiteTalk, RESTlet or Suitelet.
I am completely new to this topic and after a few days of research, I learned that there are 3 options for an API integration with netsuite (Suitelets, restlets and suitetalk which comprises REST and SOAP based web services). I also learned that there are scheduled scripts and user events, but I'm not too clear on the idea.
I need some help identifying which integration option I should choose.
Any and all information about netsuite API integration is appreciated!
I would avoid REST/SOAP. SOAP is outdated, and REST is incomplete and difficult to use.
Suitelet's are for when you want to present your own custom UI to frontend users, like a special new kind of custom form not relevant to any particular record. Probably not what you want.
What you probably want is to design a restlet. A restlet is a way for you to setup your own custom url inside NetSuite that your program can talk to from outside NetSuite. Like a webpage. You can pass in data to the restlet either inside the URL, or inside the body of an HTTP request (e.g. like a JSON object), and you can get data back out from the body of the HTTP response.
A restlet is a part of SuiteTalk. The method of authenticating a restlet is the same for the method of authenticating a request to the REST API. So, learning about SuiteTalk is helpful. The code you use to write the restlet, SuiteScript, is the same kind of code used to write suitelets and other kinds of scripts.
So you will want to learn about SuiteTalk, and then, in particular, SuiteTalk restlets.
this is a really subjective issue.
It used to be that SOAP/SuiteTalk was a little easier in terms of infrastructure and since Netsuite's offerings are ever changing the REST/SuiteTalk might fill this space in the future.
Since Netsuite deprecated the Full Access role setting up integrations almost always involves the integrator having to provide a permissions spec. The easiest way to do that is via a Bundle. For token based authentication (TBA) there also needs to be an integration record from which you need Consumer Id and Secret Tokens.
So as of this writing the set up for SOAP/SuiteTalk and RESTLets is roughly the same. The easiest way to communicate these is with a bundle so if you are a Netsuite dev with a dev account you can set these up in a bundle and have your customer import them.
So equal so far but differences:
SOAP/Suitetalk is slow. IMO not suiteable for an interactive interface
SOAP/Suitetalk the code is all in your external app so changes to the code don't require any changes in the target account.
RESTlets can be pretty speedy. I've used these for client interactions.
Updates require re-loading your bundle or overwriting your bundle files in the target account (with the resulting havoc if an admin refreshes the bundle)
RESTlets give you access to the features of the account on which you are running so that code can run appropriate chunks For instance features such as matrix items, multi-location inventory, one-world, pick/pack/ship, volume pricing, multi-currency will all change the data model of the account your code is running against. RESTlets can detect which features are enabled; SOAP/SuiteTalk cannot.
So really the only advantage at this point that I see for SOAP/Suitetalk is that code updates don't require access to the target account.
Who is making the changes? If it is your NetSuite developers, then your options are SUITELET or RESTLET.
If its your third-party application team, they own the code and the process and do all their work sitting outside of NetSuite - your option is SUITETALK/SOAP. Of course, they need to know something about NetSuite, but your business analyst would be sufficient to support them. As of 2020.1+, there is also support for native REST APIs in addition to SOAP in case you still want to use REST, but not write your own RESTLETS.
As the above comments mention, Suitetalk does perform a little slower than calling RESTLETS. So that maybe one of the deciding factors.
You may consider SUITELETs for integration only if you want to bypass all authentication schemes, by setting the suitelet as public. Highly inadvisable though.
If the third-party application supports REST APIs, you could call them directly from within NetSuite - either from user events or from scheduled scripts.
You can also consider iPAAS platforms like Dell Boomi, Celigo, Jitterbit, etc. These are general-purpose integration platforms, and make connecting one platform to another easy, with minimal coding. If your Company is already invested in these iPAAS platforms for other enterprise applications, then the choice is that much simpler.
I wish to build a Saas in the future using angular. I have always wondered how to allow users to have access to different features depending on the different packages they pay for.
For example: bronze package allows user to send 100 emails.
silver package allows user to send 200 emails.
This is a very simple example but I believe the concept will still apply.
So how do we differentiate between user accessibility to specific features?
I think you need some underlying framework - like Symfony - to build an api. Symfony with api-platform is a good choice.
Then you build your Angular app and send api-requests via fetch or axios. Symfony and api-platform handles in this case all the restriction stuff via voters and so on.
I'm looking into using AngularJS for an upcoming project but I am having difficulty getting my head around the views/routing, specifically for an app with only one page.
The page consists of a form or wizard, however I want all data to be loaded on the initial page load (and stored in local storage). This also applies to form elements - no additional requests can be made to the server e.g. for HTML templates (except the submit action at the end of the form). The application will be used offline so the single page needs to cache all required information and handle UI transitions without reloading.
Is AngularJS a good fit for such an application? If so, how can I accomplish the routing required to change views without additional requests - can ng-view and a routeProvider use div's within a single html page? Is this a case for ui-routes?
I've yet to implement such a site but I believe these are slightly orthogonal issues. AngularJS solves the issue of polluting your view with business logic (MVC), it also gives you the means to create singleton services. Further it allows you to extend the vocabulary of HTML with directives to define compound DOM elements or behaviors. All of these elements I believe are helpful in creating a user interface that is loosely coupled via a model and a controller for a view to the data retrieved and stored in services.
Local storage APIs implemented in certain browsers in response to definitions in the HTML5 spec give you the ability to persist data locally and determine when a change from online-offline has occurred, it's covered in depth on this page http://www.html5rocks.com/en/tutorials/offline/whats-offline/
Long and short of it I think AngularJS is an ideal candidate for building rich client side experiences and decoupling the model from the view and the controller (hence giving you the part you need to save separate from the application itself). All that said I'm not aware of any mechanisms built in to Angular to help make this easier, though if you Google a bit for localStorage and AngularJS there is definitely some discussion about it and code available: angularjs and localStorage change event
My understanding of web services is that they are used to provide distributable functionality. However, as RESTful web services can return HTML and show this HTML as a regular web page in the browser, we then have a view rather than business logic. Is this ever useful or is it a violation of the separation of concern principle?
You are confusing something here.
REST is a web api design model and thus focuses on the integration of different applications rather than the internal structure of those.
That being said, REST is a very relaxed model. However the corner stones of a rest system are:
Its state less
You do not have some kind of a session like with soap, where you first authenticate and then get a session id and can perform actions. In rest every call is independent and has all the data/information needed to be processed and does not rely upon any preceeding or sucessing calls
every service is uniquely adressable by a uri
there are oprations that must meet certain criteria
for example a simple web server usually servers GET requests, those must be safe, meaning they will not modify anything, they are read only
here is a good article...
http://www.codeproject.com/Articles/253944/Representational-State-Transfer-A-Short-Walkthroug
I want to design a website but I don't know from where to start.
Is there a beginners' guide to start with?
How much dedication do you hope to provide? If you merely want to design a single website, quickly and dirty, there's a plethora of open source web templates available online, with clean and basic HTML/XHTML design strategies that you could modify, and provide content for.
Such as this and that.
Alternatively, if you would like to design your own websites from scratch and have full technical knowledge in the field (the proper way). Pick up a book or two on HTML/XHTML/XML, with documentation on content management systems, php, etc.
You'd soon find that in the beginning your development would be gradual and at best, slow. If you put in sufficient effort, you would find that you get to the point where you can quickly design sites confidently, which best illuminate your content.
You should be familiar with this and this
Try this Web Design from Scratch
I understand by website you mean some kind of web-app. And by design you mean, not just the page design but the design of the web-app. First, you have to understand the anatomy of a web-app. The major components are:
Database is used to store user and application data for long term. A database provides query functionality (SQL), backup on one installation and restore on another, triggers when a data entry changes, and constraints that must be satisfied by the data tables.
Web Server, also called Http Server hosts the web application.
Web Browser such as Internet Explorer or Firefox.
When a user types a URL into the web browser, the web server forwards the URL to the corresponding web application. The web application performs the needed tasks (which may involve reading or writing into the database) and returns a new html page to the user via www.
Some components of the web application are:
Database access objects are representations of objects that encapsulate interaction with database tables.
Business Logic is the main logic of the application. Here we implement the search functionality using Lucene library, for example.
Action Handler handles a http request received from the user, for example when she types a URL or when she clicks on the "submit" button. These are Http GET and POST requests. The Action Handler uses the business logic to drive the actions.
Data view on the web brower is constructed using some template library (which usually produces javascript user interface code for the web browser). For interactivity one may use Ajax techniques.
Almost all web-apps separate the model, view and controller of a web application. The view deals with the display, the model deals with data and the controller deals with control/functioning. See http://www.uidesign.net/Articles/Papers/UsingMVCPatterninWebInter.html.
Several frameworks implement MVC. The most easy ones to get started are Ruby on Rails and Django (over which an open source social network called Pinax too is written). There are much more comprehensive frameworks and libraries in java too (for a single web appl you may need to join several of these libraries), such as spring, webwork, tapestry, lucene (for search), sitemesh (for page decoration). Many java web apps run on tomcat web server and with mysql database.
I started with http://w3schools.com. Make sure you're using Firefox and the Firebug addon. Get your hands dirty then get familiar with the web design community.
I have CSS Mastery by Andy Budd on my desk and it's a good, readable, short, yet deep guide to CSS.
Don't Make me think has also become my mantra of web design.
Overall, you're going to produce a lot of crap--as I have--before you get good. If you have someone to look over what you're doing that'll be the best help. Personal drive will matter the most in the long run though, so stick with it and keep learning.
Liz Castro has a good book too.