REST (Representational State Transfer) ialah gaya seni bina (architectural style) untuk aplikasi berangkaian, ditakrifkan oleh Roy Fielding. Ia bukan protokol atau piawai — ia satu set kekangan (constraints) yang, apabila dipatuhi, menjadikan API boleh diskala, boleh di-cache, dan mudah berkembang. API "RESTful" memodelkan segala-galanya sebagai sumber (resource) (users, orders, products) yang dikenal pasti oleh URI, dan memanipulasinya menggunakan HTTP method standard.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
URI /users/42 menamakan sumber; GET ialah tindakan; JSON ialah representasi. Gabungan itu — kata nama dalam path, kata kerja sebagai HTTP method — ialah inti REST.
REST ialah gaya dominan untuk web API, jadi penemu duga menggunakan soalan ini untuk menyemak bahawa anda memahami mengapa ia berfungsi, bukan sekadar boleh mengejanya. Dua kekangan yang paling penting dalam praktik ialah statelessness (setiap request lengkap dengan sendirinya, jadi anda boleh meletakkan sebarang bilangan server di belakang load balancer dan menskala secara mendatar tanpa sticky session) dan uniform interface (URL berorientasikan sumber yang boleh diramal serta HTTP method dan status code standard, bermakna client tidak memerlukan logik tersuai bagi setiap endpoint). Jawapan yang kukuh mengaitkan kekangan dengan manfaat konkrit — statelessness membolehkan penskalaan, cacheability mengurangkan beban, layered system membenarkan anda menyisip CDN dan gateway — dan menyatakan bahawa kebanyakan API "REST" bersifat pragmatik dan bukannya RESTful sepenuhnya (sedikit yang melaksanakan HATEOAS). Memahami kekangan ini ialah asas untuk setiap keputusan reka bentuk REST yang lain, daripada memilih status code hingga versioning.
Pustaka soalan temu duga IT dengan jawapan terperinci — daripada Junior hingga Senior.
Derma