Unified Patent Court - API Workshop

Presentation used during the Unified Patent Court API Workshop.

Transcript

1. Unified Patent Court API Workshop
2. Agenda • Introductions • Overview • Principles • Timescales • Platform • API Design • Workshop
3. Overview • API Access for Court Data • What do you need? • How will you access the data? • What will you do with it? • The Re-use of Public Sector Information Regulations 2015 • Re-use means using public sector information, for a purpose other than the initial public task it was produced for. • Typically, this would mean an individual, a company or other organisation taking information you have produced and republishing it or using it to produce a new product or resource, often by combining it with other information. This is sometimes, though not always, on a commercial basis. RPSI is intended to encourage re-use of public sector information. • RPSI is about permitting re-use of information and how it is made available. It is not about accessing information, which is dealt with under information access legislation.
4. Principles
5. Principles • Start with needs: The design process must start with identifying and thinking about real user needs. We should design around those. We must understand those needs thoroughly — interrogating data, not just making assumptions — and we should remember that what users ask for is not always what they need. • Utility computing: We prefer to use services that can be provided to us by a third party as a utility (rather like a metered service based on need) as opposed to creating or managing services ourselves.
6. Principles • Reuse: ICT will be made up of components that can be used in many different situations and shared more widely between different parts of the UPC and partners, rather than each problem or requirement being addressed individually. • Open Standards: We strongly prefer technologies that are openly available, rather than the exclusive property or product of a particular company or organisation. – ODF v1.2 Internal Documents
7. Principles • Risk based approach: We will make decisions on how to provide services based on a balanced understanding of risk and reward. • Any user device: We will provide our services to any appropriate and suitably secured device, whether or not it is owned and managed by UPC.
8. Principles • Iterate. Then iterate again: The best way to build effective services is to start small and iterate wildly. Release Minimum Viable Products early, test them with real users, move from Alpha to Beta to Launch adding features and refinements based on feedback from real users.
9. Timescales
10. Timescales • January ’16 • Initiate Handover to Luxembourg • February ‘16 • Two Factor Authentication via Mobile OTP • Via G-Cloud • Pilot Integration with STORK 2.0 / eSENS • EU eID for individuals and companies • Additional Development on Internal APIs • March ‘16 • Publish Draft External API • Via Apigee • Finalise Handover
11. Platform
12. Platform • Suppliers working together on new services / solutions • Demand for access to API • Expose platform to Citizens / Suppliers
13. API Design
14. Publish Cases Online • Draft Page • https://upc.dev.migl.co.uk/cases
15. API Design • Communications • Preferred Comms • Developer Portal? • www.programmableweb.com • API Standards • RESTful? • JSON? • XML? • Open Standards • Authentication • API Key? • OAuth? • What Data Do You Want?
16. API Design • URL? • dev.unified-patent-court.org? • developers.unified-patent-court.org? • api.unified-patent-court.org? • API Console? • https://developers.epo.org/ • Is this useful?
17. API Design • Datasets? • Cases? • Documents? • Opt-Out?
18. API Management • Investigating Apigee • Security • Caching • Monetization • End User Analytics • Throttling • Reporting • PCI Compliance • Used by EPO • EPO Console
19. Postman REST Client • Used to test RESTful APIs • Chrome Plugin • Test and document RESTful APIs • Synchronise across devices • Publish to public with documentation • Download configuration
20. Questions
21. Workshop