Can this be considered an API? - api

If I have an online database containing data about people (name, age, country etc), and then I create a page that displays information of it, and save it as: mywebsite.com/api/get_person_information/person_id
This page would simply display a serialized array (php) with information of a table's row (which primary key value should be replaced in 'person_id'). Could that be considered an Web API?

A web API is anything that lets other people make an application reusing components of your application or your data. That would make exposing your data in a machine-readable way an API.
(You might want to use a more popular format to expose said data instead of PHP's variable dump syntax.)

Related

What is the good way to collect data from screen?

For example i have a screen with multiple textfields (name, surname, address, phone etc) and after button click need to collect that data and pass to registration module. What is the good way to collect that data?
You can use multiple options here like
SQLite: Its pretty old way of saving and fetching data as it has lots of things to do while using.
Core Data: This is the most used way if you have multiple fields like first name, last name, email, mobile, gender, state, city, etc
Singleton Class with required fields: If you want to use properties on multiple places and with less number of initialisation, then go for with approach.
NSUserDefaults: Basically this should be used if you are saving some flags and small properties like user ID or user name.
plist (Property List): It is a flexible and convenient format for storing application data.
So as per my knowledge you can prefer Core Data as you good amount of fields and core data is easy way. And you can use same core data model for multiple entities when you want to add some more tables and fields in it.
1). Best way is to use FMDB if you want to store registration detail from textfield.
Download FMDB from Github
2). If you want to store and get only few registration data at a time then you can use NSUserDefaults for store data temporary and as well as retrieved.

Is it possible to restrict part of an Ektron smart form to a specific user group?

Is it possible to restrict part of a smart to only a certain user group and if the user trying to edit the smart form content is not of that group, then the user cannot change that portion of the content?
Example:
Let's say I have an Employee smart form with fields for EmployeeBio, EmployeeHireDate, and EmployeeDept. Would it be possible to allow the general author user group to be able to edit the EmployeeBio field, but restrict the EmployeeDept and EmployeeHireDate fields to only an HRAdmin user group?
If it helps, I am using Ektron 9.00 SP3.
As far as I know, you either can edit a content block or you can't; there isn't a way to subdivide permissions on a per-smartform-field basis.
What you can do, is group the "restricted" fields into their own smartform, and then reference that via a content resource selector field.
So your Employee smart form might look like this:
/root/txtName (not in your example, I know...)
/root/rtfBio
/root/cresHRID
Side note: I'm using hungarian notation on my field names here. txt indicates a plain text field, rtf indicates a rich text (html) field, and cres indicates a content resource selector.
Then you could have a second smart form... let's call it "EmployeeHR", and it would have the following structure:
/root/hireDate
/root/txtDepartment
That would, in theory, work. However, I must say that I really don't like splitting up this particular type of data in this way. First, department feels like it would function better as a taxonomy to which you could add the content block. Second, it feels like this type of data would be better served by housing it outside of ektron and then using a DxH (Digital Experience Hub) connector to bring the data into Ektron. This way the external system could handle permissions at a more granular level, and you would still have access to the data within Ektron for use elsewhere within the site.
UPDATE
As I ponder this question some more, another option comes to mind. You could write an ASPX page or UserControl that checks to make sure you're logged in and a member of a particular group before presenting you with a custom edit screen. The following code will check if the current user is a member of the admin group; you can swap out a different group id to fit your needs:
// Not sure off hand which of these using statements provides access to EkConstants...
using Ektron.Cms;
using Ektron.Cms.Common;
using Ektron.Cms.Content;
var userGroupApi = new Ektron.Cms.Framework.User.UserGroupManager();
var isInGroup = userGroupApi.IsUserInGroup(currentUserId, EkConstants.g_AdminGroup);
This could be implemented as an ASPX page on your site, or it could be implemented as a widget and placed on the user's Smart Desktop tab of the workarea. Either way, you have a lot of options for getting what you want, just nothing "out of the box".

How do you get the ID of a row in a Core Data entity, such that you can reference it later?

Small question!
With Ruby on Rails (which I appreciate talks to a "real" database), with each record I add to a table, I can extract the ID of that record, send it somewhere, do something with it, and return data which can be associated with the original record.
I can't (for the life of me) seem to find the way to do it in Core Data.
If I have a Messages Entity with rows of messages. I want to be able to extract the ID of the message (row ID?), and send it to my server, and have a response change the same record by looking up it's ID.
The closest I can get is [message objectID]. However, I have no idea what this really returns, and I can't seem to encode it in a JSON request anyway.
Sigh.
Any help would be appreciated as I really don't know where to start with this one.
Edit:
Looking at other websites, and finally drilling it down, I've decided to use my own Unique ID. Apple can change the structure of URIRepresentation and, objectID can change if you change the structure of core data. So, it's best to stick with what I know.
objectID is a unique id for an object in CoreData. Quoted from Apple
An NSManagedObjectID object is a compact, universal identifier for a
managed object. This forms the basis for uniquing in the Core Data
Framework. A managed object ID uniquely identifies the same managed
object both between managed object contexts in a single application,
and in multiple applications (as in distributed systems). Identifiers
contain the information needed to exactly describe an object in a
persistent store (like the primary key in the database), although the
detailed information is not exposed. The framework completely
encapsulates the “external” information and presents a clean object
oriented interface.
you might consider reading the documentation here and here
You can get an URIRepresentation which might help you with JSON representation.
Looking at other websites, and finally drilling it down, I've decided to use my own Unique ID. Apple can change the structure of URIRepresentation and, objectID can change if you change the structure of core data. So, it's best to stick with what I know.

REST best practices: should a store also return metadata?

I'm building my first REST API (at least trying) for a personal project.
In this project there are resources called players which hold can be in a team. According to REST API design rulebook a resource should be made either to be a document or a store and one should keeps these roles as segregated as possible.
Yet I would like to append some metadata to the team resource, eg the date the team was founded. Is it okay then for GET /teams/atlanta to return this metadata (making it a document) alongside the list of players in the team (making it a store).
Is this a good idea? If so why? If not why not and how to solve this better?
I know there are no rules to developing a REST API, but there are good practices and I would like to adhere to those. Please also not that this is really my first REST API so pardon my ignorance if there is any.
I would recommend having GET /teams/atlanta return just the information about the team, such as the founding date that you mention, and then having GET /teams/atlanta/players return the list of players for that team. These distinctions become more important when you are presenting an API that uses HTTP methods other than GET.
For example, if you wanted to add a player to a team - this would be a lot easier if you could just POST a player object to /teams/atlanta/players than if you had to PUT the whole team object to /teams/atlanta every time you wanted to add one individual player.
If your API only allows retrieval of data, and if it is for a specific client application, there is an argument for combining all the team data into one object to save the client having to make additional requests for the data, but bear in mind that it is less flexible.
Your application may want to display a list of teams by calling GET /teams but you probably wouldn't want all of the player information included in each object in the list as this is quite a lot of data, but if GET /teams/atlanta returns player information then it would be inconsistent not to include it in the list version too.
I would personally favour splitting up the resources as I've suggested, and live with the fact the client may need to make an extra request or two.

Structured data in Joomla

I'm currently developing a back-end for chefs at various restaurants to report their daily menues in a structured format. Of pragmatic reasons have I chosen to use a web CMS and use many of the features already include including a flexible rights-management module
I want to utilise the existing functions in Joomla for access control, editing and navigation, but I need to replace the textfield with five field (each representing one day of the working week) and save this in a structured way into the database. I was planning to create a editor plugin which displays the field for the chef-users and parse the in-data into a structured data-format e.g. XML. For each week I will need to create empty templates for all the restaurants displaying the week number and dates.
I was also hoping for third-party developers to access this data through RESTful methods in the URL where the structure could be something like: http://domain.no/restaurant-name/menu for a text-menu http://domain.no/restaurant-name/json for json etc.
I guess my question is how I can start developing such features. Has there been developed anything similar and are there modules developed for Joomla which I can utilise? Does my approach sounds sensible or are there any other good way of solving my problem?
For a custom content management i would use Zoo component from Yootheme (not free!). You can define your fields,
But for developers access, i have no idea, sorry!