Editors note: Article written by Tyler Band for Espresso Logic.
Having built REST servers from scratch, I can confidently say that building REST server from scratch takes a lot of code and time. There are several vendors which provide service platforms to connect and expose database tables as REST endpoints. Once the endpoints are exposed, these are not quite ready for the mobile developers to consume yet as the API just looks relational rather than document oriented. tFor the real challenges of building an enterprise mobile back-end server, here arehe 5 critical REST services every mobile development team must have:
Custom Resources Endpoints
Access Control and Security
1. Custom Resource Endpoints ? The main goal of a mobile developer is to limit the number of requests to the server. The ability to create a nested muti-table document is essential. These new resources should be able to ?join? data from multiple databases, tables, views, procedures, NoSQL, or other back-end services. To the mobile front-end, it is all just JSON.
2. Multi-table Update (Primary key propagation) ? If we provide a new nested document that exposes a parent and its children then the server must handle the POST (insert) by knowing that the primary key of the parent is needed as a foreign key in one or more children (Shopping Cart Customer, Orders, and Items). This then introduces the need for multi-table transactions ? it inserts or if a validation fails the transaction is rolled back.
3. Optimistic Locking ? Most of the database experts are wondering how a mobile front-end is going to handle state-less transactions. Best practice is to hash the row and include this in the GET request. This avoids having to add a timestamp to every single table.
4. Pagination ? The mobile front-end can always append a search filter to every request. Best practice is to allow page limits to be specified at the server. These batch limits should be applied to each nested level of the document and a forward link to the next batch to simplify the mobile developers paging.
5. Role-based access control & row/column security ? The corporate security policy around identity management (aka. authentication) and role-based access to resources must extend to the REST services as well. This means that the users role(s) will determine which resource endpoints are exposed and what operations this role can perform (e.g. READ, INSERT, UPDATE, DELETE). Further, the service must extend down to each table to add a filter to every request (e.g. an employee can only see his/her own records).
Many vendors will connect you to your database, but you will need to ask these 5 questions and make sure your back-end team can deliver. The folks at Espresso Logic have been around databases for decades and have seen these types of issues. Their elegant and simple point-and-click approach and the fully integrated features are out-of-the box and not an after-thought. One feature I failed to mention is the POST/PUT response includes a complete transaction and business logic summary of all the new values in every table that was impacted by the changes. This is a true performance gift for mobile refresh. Check more about our REST API here.